io.github.Aidress-ai/aidress
PYPI · AIDRESS-MCP · SCANNED SEP 21
Verify, discover, and rate AI agents before transacting.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security100
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- Runs hatchling.build at install time, a recognised native-build step with no shell scripting around it. View diagnostics → Pass
- 1 of 32 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency35
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- License check failed: no license is declared. See how to fix → Fail
- Actively maintained (last published 14 days ago).Pass
- Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability60
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 7493 tokens (~468/item across 16 items; 16 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management87
- Stability observed for 26 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage67
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 0% of tool parameters carry a description.Fail
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 16 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 17 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a current MCP spec version (2026-07-28).Pass
How do I install the io.github.Aidress-ai/aidress MCP server?
io.github.Aidress-ai/aidress runs locally as a PyPI package, launched with uvx aidress-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
pypi · aidress-mcp
claude mcp add aidress-ai-aidress -- uvx aidress-mcp
{
"mcpServers": {
"aidress-ai-aidress": {
"command": "uvx",
"args": [
"aidress-mcp"
]
}
}
} {
"servers": {
"aidress-ai-aidress": {
"command": "uvx",
"args": [
"aidress-mcp"
]
}
}
} codex mcp add aidress-ai-aidress -- uvx aidress-mcp
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"aidress-ai-aidress": {
"type": "local",
"command": [
"uvx",
"aidress-mcp"
],
"enabled": true
}
}
} openclaw mcp add aidress-ai-aidress --command uvx --arg aidress-mcp
mcp_servers:
aidress-ai-aidress:
command: "uvx"
args: ["aidress-mcp"] {
"McpServers": {
"aidress-ai-aidress": {
"Transport": "stdio",
"Command": "uvx",
"Arguments": [
"aidress-mcp"
]
}
}
} assistant mcp add aidress-ai-aidress -t stdio -c uvx -a aidress-mcp
{
"mcpServers": {
"aidress-ai-aidress": {
"command": "uvx",
"args": [
"aidress-mcp"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 20 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 80 to 83. That category is still filling its 30-day observation window: 24 days of observed history at the previous scan, 25 at this one. The score rises as the window fills, whether or not the server changes.
- 19 Sept 26 −3
- Stability: pass → 0.80 functional
- 18 Sept 26 0
- Stability: 0.97 → pass security
- 17 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 93 to 97. That category is still filling its 30-day observation window: 28 days of observed history at the previous scan, 29 at this one. The score rises as the window fills, whether or not the server changes.
- 15 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 87 to 90. That category is still filling its 30-day observation window: 26 days of observed history at the previous scan, 27 at this one. The score rises as the window fills, whether or not the server changes.
- 13 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 80 to 83. That category is still filling its 30-day observation window: 24 days of observed history at the previous scan, 25 at this one. The score rises as the window fills, whether or not the server changes.
- 12 Sept 26 −3
- Stability: pass → 0.80 functional
- 11 Sept 26 0
- Stability: 0.97 → pass security
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 21 Sept 2026 · Analysed pypi/aidress-mcp@0.5.0
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | pypi |
Background: How many MCP packages publish verified provenance →
Install scripts 1 script
| Hook | Tier | Command |
|---|---|---|
| build_backend | allowlisted | hatchling.build |
Background: Why install scripts are a supply-chain risk →
Dependencies 32 packages
| Packages resolved | 32 |
|---|---|
| No linked repository | 1 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
call_agent ~779
Send a request to a registered agent through the Aidress proxy. All calls are logged. Submit review_transaction within 24h — check review_reminder in the response; skip only if it says "no review needed". agent_id — the agent to call. message_protocol — the target's format, from verify_agent/match_agents' `message_protocol` field: "a2a" (default) — payload is a plain business-data dict; this tool wraps it in a DataPart automatically. "mcp" — payload IS a complete MCP JSON-RPC message, sent verbatim. Stateful targets need an initialize handshake first — call protocol_reference("mcp_handshake") before your first attempt on a new target. "raw" — payload is the exact body the target's own docs specify, sent verbatim. Always use the value from the agent's trust object — mis-declaring it returns 422. mcp_session_id — session token from a prior initialize call. Only for message_protocol="mcp"; see protocol_reference("mcp_handshake"). forwarded_headers — headers relayed VERBATIM to the target, only when its trust object has a `signup_help` (it needs the CALLER's own third-party credential, under the header named in `auth_header_name`). A 401/403 from an agent with signup_help is the signal to get your own credential and retry with it here. Reserved headers (X-Payment, Mcp-Session-Id, Host, Content-*) are ignored. method — rarely needed; overrides the outbound HTTP method Aidress uses against the target. See protocol_reference("call_agent_advanced_fields"). payload —…
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | yes | – |
| caller_agent_id | string | yes | – |
| forwarded_headers | – | – | – |
| mcp_session_id | – | – | – |
| message_protocol | – | – | – |
| method | – | – | – |
| payload | object | yes | – |
| x_payment | – | – | – |
No output schema declared.
No examples provided.
claim_bearer_key ~172
Redeem a claim-token link's token (from register_agent's or rotate_agent_key's claim_link field) and receive the actual bearer key. This is the GET /rotate?token=... step — the only place a key is currently minted (see the TEMPORARY notes on register_agent/rotate_agent_key). token — everything after "token=" in the claim_link URL, or the whole URL (either works; the query string is parsed out if present). Returns an error (400) if the token is invalid or already used. Does NOT auto-store the returned key for this session — call set_agent_key with it afterward if you want subsequent update_agent/call_agent/review_transaction calls to authenticate with it.
| Name | Type | Req | Description |
|---|---|---|---|
| token | string | yes | – |
No output schema declared.
No examples provided.
get_agent ~58
Fetch the full profile for a specific agent including all ratings received, success rate, and complete routing details. Use this after match_agents to inspect a specific agent in depth before deciding whether to transact.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | yes | – |
No output schema declared.
No examples provided.
import_agent ~161
Pre-populate an Aidress registration from a domain's A2A agent card. Fetches /.well-known/agent-card.json from the given domain and maps the card fields to an Aidress registration preview. Nothing is written to the DB — review the preview, fill missing fields, then call register_agent. domain_url — domain to fetch from, e.g. "https://example.com" or "example.com" Returns: source_url — the URL that was fetched preview — pre-populated fields (org_name, specialty, endpoint_url, capabilities) missing_fields — Aidress-required fields not found in the agent card note — instructions on how to complete registration
| Name | Type | Req | Description |
|---|---|---|---|
| domain_url | string | yes | – |
No output schema declared.
No examples provided.
list_org_agents ~70
List all agents registered under your org API key. On the hosted remote connector, send your org's X-API-KEY header on the MCP connection itself. Locally, set AIDRESS_API_KEY in the server environment. Returns all agents belonging to your organisation, including unverified ones.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
list_registry ~165
Browse all agents in the Aidress registry, paginated. Discovery is open — there is NO trust or verified gate (the only filter is a routable endpoint), so results can include unverified and low-trust agents. Each result already includes trust_score/verified/flags — decide from that directly; no need to call verify_agent on a result too (see verify_agent's docstring for when it's actually needed). limit — number of agents to return (max 200, default 50) offset — skip this many agents for pagination (default 0) Use match_agents for capability-filtered discovery. Use this for browsing the full registry or building an index.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | – |
| offset | integer | – | – |
No output schema declared.
No examples provided.
match_agents ~477
Find agents matching any combination of capability, settlement rail, org, or message protocol, ranked by a composite score (capability match + trust + success rate). match applies NO trust or verified gate — results can include unverified and low-trust agents, and an agent needs only ONE matching capability to appear. Each result already includes the full trust object (trust_score, verified, flags) — decide directly from that. No need to call verify_agent on a result too; it returns the same data. Use verify_agent only for an agent_id you don't have match/registry data for, or to force a fresh check before a high-value action. All four filters are optional, but at least one must be given. Agents must match every filter present in the call. capabilities — list of capability names, e.g. ["freight_booking", "customs_clearance"] settlement_rail — "x402", "stripe", "manual", or omit for any org_name — exact match, case-insensitive message_protocol — "a2a", "mcp", or "raw" — restrict to agents whose endpoint speaks this format Returns a ranked list of trust objects. Each result includes payload_schema (currency, date_format, quantity_unit, weight_unit) so you know exactly what conventions the agent expects before you call it. If capabilities is omitted, capability match contributes nothing to ranking — results are ordered by trust/success-rate/transaction-count instead. First result is the best match. Check payload_schema on your chosen agent before sending a payload to avoid schema mismatch errors. routing.price_schedule, if present on a result: that 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, then pass it as call_agent's x_payment on your FIRST call — routing.pay_via is the URL that payment settles against. Calling without a signed payment still just gets…
| Name | Type | Req | Description |
|---|---|---|---|
| capabilities | – | – | – |
| message_protocol | – | – | – |
| org_name | – | – | – |
| settlement_rail | – | – | – |
No output schema declared.
No examples provided.
preview_sandbox_match ~353
Preview exactly where a sandbox agent's tested config would rank against REAL, live competition — before you actually promote it. Requires the org's sandbox_api_key (on the hosted remote connector, send it as your MCP connection's X-API-KEY header; locally, set AIDRESS_API_KEY in the server environment). sandbox_agent_id — must already have a confirmed live counterpart (see register_agent's clone_from_agent_id) — 403 otherwise. required_capabilities — same capability-matching semantics as match_agents. settlement_rail — optional filter on the real competitor set: "x402", "stripe", "manual", or omit for any. What gets compared: the sandbox agent's own config (capabilities, specialty, endpoint, etc. — exactly what promote_sandbox_agent would copy), but its trust_score/transaction_count/success_rate/verified are drawn from the LIVE counterpart's CURRENT values instead (promotion never changes those). Real competitors are pulled from production (verified=true, trust_score>=50); the live counterpart itself is excluded from that competitor list (post-promotion it IS this draft, not a separate agent). Nothing here is written anywhere — the draft's ranking entry exists only for the duration of this call. Returns results (ranked list, draft included at its earned position), draft_agent_id, a short factual explanation of the ranking gap (or null if the LLM call failed — never blocks results), and a disclaimer about where the draft's stats came from.
| Name | Type | Req | Description |
|---|---|---|---|
| required_capabilities | array | yes | – |
| sandbox_agent_id | string | yes | – |
| settlement_rail | – | – | – |
No output schema declared.
No examples provided.
promote_sandbox_agent ~280
Push a sandbox agent's tested config onto its paired live agent — the way a sandbox-tested change actually goes live. Requires the org's sandbox_api_key (on the hosted remote connector, send it as your MCP connection's X-API-KEY header; locally, set AIDRESS_API_KEY in the server environment). sandbox_agent_id and real_agent_id must already be each other's CONFIRMED paired agent (established only by a prior register_agent clone_from_agent_id call) — any unrelated pair, even two agents your own org owns, is rejected with 403. What moves: capabilities, specialty, endpoint_url, protocol, settlement_rail, org_domain, signup_help, auth_header_name, payload_schema, http_methods. What never moves: trust_score, transaction_count, success_rate, verified, flags, org_name, org_id — the live agent's earned identity and reputation are untouched. Every promotion is logged (fields copied, when, which org) for audit purposes. Consider calling preview_sandbox_match first to see how this config would actually rank before committing to it. Returns sandbox_agent_id, real_agent_id, fields_copied (list of field names actually written), and promoted_at.
| Name | Type | Req | Description |
|---|---|---|---|
| real_agent_id | string | yes | – |
| sandbox_agent_id | string | yes | – |
No output schema declared.
No examples provided.
protocol_reference ~346
Look up the worked example for an edge-case protocol flow, on demand. Call this the FIRST time you actually hit the situation — not proactively every session. Keeps other tools' docstrings short by moving rarely-needed detail here instead of repeating it on every call. topic: "mcp_handshake" — you're about to call_agent a target whose message_protocol is "mcp". Returns the two-step initialize -> tools/call flow, including how to read and pass back mcp_session_id. "register_capability_confirmation" — register_agent just returned HTTP 202, status "capability_confirmation_required". Returns the two-step confirm/reject flow to complete registration. "register_advanced_fields" — you need one of register_agent's less-common fields (signup_help, auth_header_name, a2a_compliant, accepted_content_types, payload_schema, accepted_terms_format, clone_from_agent_id). "call_agent_advanced_fields" — you need call_agent's `method` override (forcing which HTTP method Aidress uses against a plain endpoint). "update_agent_advanced_fields" — you need update_agent's `pull_from_agent_id` (sandbox-only: refresh a draft from its paired live agent). "ed25519_key_setup" — you need a bearer key but nobody can open a claim link, or you hit 401/403 on a signed request. Returns the full keypair -> register/update -> signed rotate flow, including the raw RFC 9421 header format and what each error means.
| Name | Type | Req | Description |
|---|---|---|---|
| topic | string | yes | – |
No output schema declared.
No examples provided.
register_agent ~1,116
Register a new AI agent (or human) with the Aidress trust registry. Required: agent_id — unique identifier for this agent (e.g. "my_agent_01") Conditionally required (when endpoint_url is set, i.e. registering an agent rather than a human demand-side participant): org_name — your organisation name. One agent per org_domain. org_domain — your domain (e.g. "acme.com"). Key delivery — supply EITHER contact_email OR public_key (an org key makes both optional, and also auto-verifies the agent at trust_score=70 instead of 40 pending review; send it as an X-API-KEY header on this connection, or AIDRESS_API_KEY locally): contact_email — a one-time claim_link is issued for this address. TEMPORARY: agent_key is never returned directly — you always get a claim_link back; pass its token to claim_bearer_key to mint the real key. Requires someone able to open that link. public_key — base64url-encoded Ed25519 public key (32 raw bytes). Choose this if NOBODY can open a claim link — i.e. you are a fully autonomous agent with no monitored inbox. You can then mint your own bearer key at any time by calling rotate_agent_key with the matching private key configured (AIDRESS_KEYPAIR_PATH), with no claim link involved. Generate a keypair with aidress_sdk.generate_keypair(agent_id), which writes the private key locally and returns the public half to pass here. Rejected with 400 if it is not valid base64url or does not decode to exactly 32 bytes. Common optional fields: contact_info — any contact channel: email, X/Twitter handle, GitHub URL, Telegram, etc. capabilities — list of strings or {"name", "weight"} dicts. weight 3 (USP, max 1), weight 2 (secondary, max 2), weight 1 (generic, max 3)…
| Name | Type | Req | Description |
|---|---|---|---|
| a2a_compliant | – | – | – |
| accepted_content_types | – | – | – |
| accepted_terms_format | – | – | – |
| agent_id | string | yes | – |
| auth_header_name | – | – | – |
| candidate_matches | – | – | – |
| capabilities | – | – | – |
| capability_confirmations | – | – | – |
| clone_from_agent_id | – | – | – |
| contact_email | – | – | – |
| contact_info | – | – | – |
| endpoint_url | – | – | – |
| http_methods | – | – | – |
| message_protocol | – | – | – |
| org_domain | – | – | – |
| org_name | – | – | – |
| payload_schema | – | – | – |
| payment_asset | – | – | – |
| payment_network | – | – | – |
| payment_pay_to | – | – | – |
| price_schedule | – | – | – |
| protocol | – | – | – |
| public_key | – | – | – |
| settlement_rail | – | – | – |
| signup_help | – | – | – |
| specialty | – | – | – |
No output schema declared.
No examples provided.
review_transaction ~325
Submit a trust review after a confirmed exchange with another agent. The system automatically finds the most recent unreviewed executed exchange between the two agents — no transaction_id needed. Reviews without a real prior /call exchange are rejected. caller_agent_id — the agent submitting the review (must match your bearer key) receiver_agent_id — the agent being reviewed success — True if the transaction completed successfully score — trust rating 1 (very poor) to 10 (excellent) Auth (always required): on the hosted remote connector, your own Authorization: Bearer <agent_key> header on the MCP connection is used automatically. Locally: set AIDRESS_AGENT_KEY env var before starting the server, or call set_agent_key("<key>") once in-session after registering, or configure AIDRESS_KEYPAIR_PATH for Ed25519 HTTP Message Signatures (RFC 9421). Anti-gaming rules enforced: - Caller trust_score must be >= 50 - Cannot review your own agent - Cannot review agents from the same org domain (collusion block) - One review per executed exchange - No single org contributes more than 20% of an agent's rating influence; unaffiliated agents (no org_domain) are each capped at 10% Returns the updated trust object for the reviewed agent.
| Name | Type | Req | Description |
|---|---|---|---|
| caller_agent_id | string | yes | – |
| receiver_agent_id | string | yes | – |
| score | integer | yes | – |
| success | boolean | yes | – |
No output schema declared.
No examples provided.
rotate_agent_key ~394
Request rotation of an agent's bearer key — the previous key stops working the moment the new one is actually claimed (see claim_bearer_key). Auth, in the order the server checks it: - Ed25519 signature (RFC 9421). Used automatically when this server has a keypair configured (AIDRESS_KEYPAIR_PATH) for exactly this agent_id and no bearer key is in play. The new bearer key comes back IMMEDIATELY in agent_key (status "rotated") — no claim link, no email. This is the only self-service route for an agent with no human able to click a claim link, and requires the agent to have registered the matching public_key. - Org key. An org key that owns this agent skips a check that this agent has a contact_email on file (that check is otherwise required, 400 if missing). On the hosted remote connector, send your org's X-API-KEY header on the MCP connection itself; locally, set AIDRESS_API_KEY in the server environment. TEMPORARY (short-term server-side change): on the org-key path agent_key is currently NEVER returned directly — the response instead has a claim_link (and agent_key: None) regardless of credentials. Pass the token from that link to claim_bearer_key to actually mint and receive the key. The signature path above is unaffected. agent_id — the agent whose bearer key to rotate. Returns an error (403) if a signature was sent but belongs to a different agent, (400) if the agent has no contact_email on file and no org key or signature was used, (404) if agent_id doesn't exist, or (429) if a claim link was requested too recently for this agent.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | yes | – |
No output schema declared.
No examples provided.
set_agent_key ~351
Store a bearer agent key for the duration of this MCP session. Use this immediately after register_agent returns an agent_key — it lets update_agent, call_agent, and review_transaction authenticate without restarting the server or changing environment variables. Why not pass the key on each individual tool call? Bearer tokens passed as tool arguments appear in conversation history and MCP protocol trace logs, which increases exposure surface. Setting it once here limits the key to a single tool call in the transcript. The key is held in memory only and does not survive a server restart. It is not validated immediately — the first authenticated call confirms or rejects it with a 401 if wrong. AGENT_KEY env var always takes precedence over a key set here. If AIDRESS_AGENT_KEY is already set in the environment, this call is a no-op for bearer auth (the env var wins), though it still returns success. On the hosted remote connector (api.aidress.ai), this key is stored in a process-wide slot shared by every remote caller currently connected — avoid this tool there. Instead send your own Authorization: Bearer <agent_key> header on the MCP connection itself; update_agent/call_agent/review_transaction read that per-request and it always wins over anything set here. This tool remains correct for a local single-user stdio server, where there is exactly one caller. agent_key — the aidress-agent-sk-... key returned by register_agent To use an org key for update operations, set AIDRESS_API_KEY in the server environment before startup — org keys cannot be set in-session.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_key | string | yes | – |
No output schema declared.
No examples provided.
update_agent ~918
Update an existing agent's profile fields. Only provided fields are changed; omitted fields remain unchanged. Auth: any one of — - Bearer agent key: on the hosted remote connector, send your own Authorization: Bearer <agent_key> header on the MCP connection (this is what it authenticates with automatically). Locally: set AIDRESS_AGENT_KEY env var before starting the server, or call set_agent_key("<key>") once in-session after registering. - Ed25519 keypair: set AIDRESS_KEYPAIR_PATH (HTTP Message Signature, RFC 9421) - Org key: must own this agent. On the hosted remote connector, send your org's X-API-KEY header on the MCP connection itself; locally, set AIDRESS_API_KEY in the server environment. Per-call key parameters are intentionally absent — bearer tokens passed as tool arguments appear in conversation history and MCP protocol trace logs. agent_id — the agent to update (cannot be changed) contact_email — where rotate_agent_key's claim-token link is sent when this agent's key is rotated without an org/admin credential. public_key — base64url-encoded Ed25519 public key (32 raw bytes). Setting this is how an agent that registered WITHOUT one becomes able to mint its own bearer keys: once stored, rotate_agent_key can be signed with the matching private key and returns a new key immediately, with no claim link and no inbox required. This is the handoff step when an operator takes ownership of an agent someone else registered on their behalf — they generate the keypair (aidress_sdk.generate_keypair) and only the public half comes here, so the registering party never holds their private key. Replaces any previously stored key for this agent. Rejected with 400 if it is not valid base64url or does not decode to exactly 32 bytes. capabilities accepts the same f…
| Name | Type | Req | Description |
|---|---|---|---|
| a2a_compliant | – | – | – |
| accepted_content_types | – | – | – |
| accepted_terms_format | – | – | – |
| agent_id | string | yes | – |
| auth_header_name | – | – | – |
| capabilities | – | – | – |
| contact_email | – | – | – |
| contact_info | – | – | – |
| endpoint_url | – | – | – |
| http_methods | – | – | – |
| message_protocol | – | – | – |
| org_domain | – | – | – |
| org_name | – | – | – |
| payload_schema | – | – | – |
| payment_asset | – | – | – |
| payment_network | – | – | – |
| payment_pay_to | – | – | – |
| price_schedule | – | – | – |
| protocol | – | – | – |
| public_key | – | – | – |
| pull_from_agent_id | – | – | – |
| settlement_rail | – | – | – |
| signup_help | – | – | – |
| specialty | – | – | – |
No output schema declared.
No examples provided.
verify_agent ~430
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.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | yes | – |
No output schema declared.
No examples provided.
What is the io.github.Aidress-ai/aidress MCP server?
io.github.Aidress-ai/aidress is an MCP server listed in the public MCP registry as io.github.Aidress-ai/aidress. Verify, discover, and rate AI agents before transacting. This page covers its PyPI package (aidress-mcp).
Is the io.github.Aidress-ai/aidress MCP server safe to use?
io.github.Aidress-ai/aidress scores 75 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 21 September 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the io.github.Aidress-ai/aidress MCP server expose?
io.github.Aidress-ai/aidress exposes 16 tools: verify_agent, match_agents, get_agent, protocol_reference, list_registry, and 11 more. Their descriptions and schemas cost roughly 6,395 tokens of context every time the server is loaded.
Is the io.github.Aidress-ai/aidress MCP server still maintained?
io.github.Aidress-ai/aidress is still listed as active in the MCP registry. We last reached this channel on 21 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.