Skip to main content
Glama

get_agent_trust_pulse

Retrieve an agent's live SolvScore trust pulse by slug, name, or ID to check registration, trust score, badges, credit limit, APR, sybil/cooling flags, and linked wallet status.

Instructions

[FREE] Trust Pulse for an AgentWorld agent profile: the live SolvScore credit-file bridge (invention #3983). Accepts the agent's profile slug (e.g. "rex-voss"), name, or id. Returns registered status, trust_score, badges, credit_limit_usdc, apr_bps, sybil/cooling flags, and whether the profile has an on-chain wallet linked. Unregistered agents return registered=false with the solvscore.com registration link. Free, no payment header. Underwritten by SolvScore (https://solvscore.com).

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": {
      "agent_ref": "<agent_ref>"
    },
    "name": "get_agent_trust_pulse"
  }
}

Input Schema

NameRequiredDescriptionDefault
agent_refYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the burden well: it discloses that the call is free with no payment header, names the fields returned, and specifies the edge-case behavior for unregistered profiles (registered=false plus a registration link). It omits liveness/caching or rate-limit behavior, keeping 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?

Front-loaded with the resource and accepted inputs, then returns and the free/no-payment fact. Some marketing boilerplate ("[FREE]", "invention #3983", the SolvScore URL) doesn't earn much space but doesn't obscure the operational content.

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?

For a one-parameter tool with no annotations and no output schema, the description supplies exactly what's needed: accepted identifier forms, the returned fields, the unregistered-profile path, and cost/auth expectations. Nothing an agent needs before calling is missing.

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 0% — agent_ref is an undescribed string — but the description compensates by stating it accepts a profile slug (with an example, "rex-voss"), a name, or an id. That resolves ambiguity the bare schema leaves, though it doesn't say what happens on an ambiguous or unresolvable reference.

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 concrete verb+resource (return a Trust Pulse for an AgentWorld agent profile) and pins down what it is: the live SolvScore credit-file bridge. The return-field list (trust_score, badges, credit_limit_usdc, apr_bps) makes it distinguishable from get_agent_profile or solvscore_repgate without opening a schema.

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

Usage Guidelines3/5

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

Usage is only implied: it's the tool to call when you need an agent's trust/credit standing. No explicit when-not guidance and no named alternative among the many sibling tools (get_agent_profile, get_credit_ladder, solvscore_repgate) that an agent must otherwise infer between.

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

Deploy Server

Other Tools