Skip to main content
Glama
Aidress-ai

Aidress

Official
by Aidress-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

verify_agent

Look up an agent's trust profile by agent_id to get trust_score, verified status, flags, and payload_schema before transacting.

Instructions

Look up an agent's trust profile by agent_id.

NOT required after match_agents/list_registry — both already return this same trust object (trust_score, verified, flags, routing, payload_schema) for every result, so decide directly from there instead of re-fetching it here. Use this tool when you have an agent_id from somewhere else (named directly by a user or counterpart, not from match_agents/list_registry), or want a fresh read before a high-value action on data that might be stale.

Returns trust_score (0–100), verified status, capabilities, flags, routing info, and payload_schema (the semantic conventions the agent expects: currency, date_format, quantity_unit, weight_unit). Returns a 404 error if the agent_id is not in the registry — treat this as "do not transact" (same as score 0).

Trust tiers: 1–49 — low trust (40 = pending review) → transact with caution only: higher risk than 50–69, require escrow/staged delivery AND human sign-off, low value only 50–69 — caution → proceed only with safeguards 70–100 — trusted → proceed

Always check payload_schema before calling an agent so your payload uses the correct currency, units, and date format.

routing.price_schedule, if present: this agent's price is already known — no live 402 needed to learn it. To skip the 402 entirely, sign an x402 payment yourself using routing.price_schedule (task + amount), routing.payment_network, routing.payment_pay_to, and routing.payment_asset (network/recipient/asset the payment must be signed for), then pass it as call_agent's x_payment on your FIRST call to this agent — routing.pay_via is the URL that payment settles against. Skip any of this and you still just get a normal 402, same as always; the price alone doesn't skip it, only an actual signed payment does.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
agent_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.5

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: return fields, a 404 semantic mapped to 'do not transact', trust-tier thresholds with recommended safeguards, staleness reasoning, and the x402 price-schedule/payment path. This is far beyond what annotations would normally supply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Key routing information is front-loaded well, but the definition is bloated: the long x402/payment-signing passage is really call_agent guidance embedded in a lookup tool's description. That material is relevant context but dilutes the core purpose and could be trimmed or cross-referenced.

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?

No output schema exists, yet the description enumerates the returned trust object (trust_score, verified, capabilities, flags, routing, payload_schema) and explains the payload_schema fields and the 404 outcome. An agent has everything needed to interpret the result and act on it.

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 0% and the sole required parameter agent_id has no description in the schema. The description gives useful semantic context for where the agent_id should come from (user/counterpart-supplied vs. a registry result), but adds nothing about its format or validity constraints, so it only partially compensates.

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?

The first sentence gives a precise verb+resource ('Look up an agent's trust profile by agent_id'), and the second explicitly distinguishes it from siblings match_agents and list_registry, which already return the same trust object. An agent can pick this tool over its siblings without opening any schema.

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?

It states exactly when NOT to use it ('NOT required after match_agents/list_registry'), when TO use it (agent_id obtained from elsewhere, or a fresh read before a high-value action on potentially stale data), and names the alternative. This is explicit routing guidance.

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