Skip to main content
Glama

Trust Bundle: should I trust this agent? ($0.04)

trust_agent
Read-only

PAID $0.04 USDC. One call before you pay, trade with or let through an outside agent, wallet or token: allow / caution / block, a 0-100 trust score and plain-English reasons. Combines Counterparty Check, wallet profile and (for tokens) the token security verdict. Chains base, ethereum, solana. No charge on failure.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "address": "<address>"
    },
    "name": "trust_agent"
  }
}

Input Schema

NameRequiredDescriptionDefault
chainNo
addressYesAgent wallet, token contract or Solana mint
api_keyNoOptional prepaid key (sk_scrapling_...) or catalog pass token (sdp_..., from pass_day/pass_month). Otherwise pay per call with x402 via _meta['x402/payment'].

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / api_key / description
      Previous value: -"Optional prepaid key (sk_scrapling_...). Otherwise pay per call with x402 via _meta['x402/payment']."New value: +"Optional prepaid key (sk_scrapling_...) or catalog pass token (sdp_..., from pass_day/pass_month). Otherwise pay per call with x402 via _meta['x402/payment']."
  2. Added

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value annotations don't: cost ($0.04 USDC), a failure policy ('no charge on failure'), the composition of sub-checks, and supported chains. It stops short of describing latency, caching, or how allow/caution/block 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?

Compact and front-loaded: cost and the when-to-use condition come first, then the output shape, then composition and chains. Slight redundancy with the title and the terse 'PAID $0.04 USDC.' fragment costs a point but nothing is wasted.

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?

No output schema, and the description compensates by naming the return shape (verdict, score, reasons) and the composition of sub-judgments. Payment paths live in the schema, so the definition is largely self-sufficient. Minor gaps: no detail on what distinguishes caution from block, or what data is unavailable on a given chain.

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?

Schema coverage is 67% and the schema already documents the address field (agent wallet, token contract, Solana mint) and api_key payment options. The description only restates chain support ('Chains base, ethereum, solana') and hints that token security applies 'for tokens', adding little beyond the enum and field descriptions. Baseline 3 is appropriate.

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?

States a specific verb and resource: a trust verdict (allow/caution/block) with a 0-100 score and plain-English reasons, plus that it aggregates Counterparty Check, wallet profile and token security verdict across base/ethereum/solana. That distinguishes it from the narrower siblings (counterparty_check, wallet_profile, token_verdict) by implication of aggregation, though it never names them as alternatives explicitly.

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?

Gives clear triggering conditions: 'One call before you pay, trade with or let through an outside agent, wallet or token'. This supplies concrete context for when to reach for it, but no explicit when-not-to-use guidance or named alternatives (e.g. use lookup_token_risk for token-only checks).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.