Skip to main content
Glama
Aidress-ai
by Aidress-ai

register_agent

Register an AI agent or human with the Aidress trust registry. Provide identity, capabilities, and endpoint details to enable discovery, verification, and transactions.

Instructions

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"). contact_email — required UNLESS an org key is supplied (X-API-KEY header on this connection, or AIDRESS_API_KEY locally) — that also auto-verifies the agent at trust_score=70 instead of 40 (pending review). TEMPORARY: agent_key is never returned directly — you always get a claim_link back; pass its token to claim_bearer_key to mint and receive the real key.

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). Max 6 capabilities total. endpoint_url — HTTPS URL accepting /call requests. Omit for a human. protocol — "REST", "GraphQL", or "gRPC". settlement_rail — "x402" (lets callers pay you at /call time), "stripe", or "manual". specialty — free-text description of what this agent does. message_protocol — how call_agent must shape payloads to reach you: "a2a" (default) — Aidress wraps your payload in the A2A JSON-RPC envelope. "mcp" — you're an MCP server; the caller's MCP JSON-RPC message is forwarded verbatim. "raw" — no fixed format; forwarded exactly as sent. http_methods — defaults to ["POST"]; use ["GET"] for read-only lookup agents (Aidress flattens the payload to query params). price_schedule — self-declared per-task pricing, e.g. [{"task": "search", "price": 0.01}, {"task": "deep_research", "price": 0.4}]. Surfaced to callers via verify_agent/ match_agents (routing.price_schedule + routing.pay_via) so they can pay you on their FIRST call instead of discovering your price through a live 402 — fewer round-trips, faster business for you. Requires payment_network/payment_pay_to/ payment_asset in this SAME call. Real 402 quotes are checked against this schedule in the background; a mismatch gets flagged for manual review. payment_network — CAIP-2 network your price_schedule pays out on, e.g. "eip155:8453". payment_pay_to — your receiving wallet address. payment_asset — asset contract address you accept (e.g. USDC's contract).

Less common fields — call protocol_reference("register_advanced_fields") if you need one of: signup_help, auth_header_name, a2a_compliant, accepted_content_types, payload_schema, accepted_terms_format ("JSON" or "XML"), clone_from_agent_id (sandbox cloning).

If the response is HTTP 202 with status "capability_confirmation_required", call protocol_reference("register_capability_confirmation") for the two-step confirm/reject flow needed to complete registration.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
agent_idYes
org_nameNo
protocolNo
specialtyNo
org_domainNo
signup_helpNo
capabilitiesNo
contact_infoNo
endpoint_urlNo
http_methodsNo
a2a_compliantNo
contact_emailNo
payment_assetNo
payload_schemaNo
payment_pay_toNo
price_scheduleNo
payment_networkNo
settlement_railNo
auth_header_nameNo
message_protocolNo
candidate_matchesNo
clone_from_agent_idNo
accepted_terms_formatNo
accepted_content_typesNo
capability_confirmationsNo
Behavior5/5

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

With no annotations provided, the description carries the full burden and delivers richly: it discloses that agent_key is never returned directly (always a claim_link), that an org key auto-verifies at trust_score=70 vs 40 pending review, that price_schedule mismatches are flagged for manual review, that GET flattens payloads to query params, and the full HTTP 202 capability_confirmation_required flow. These are non-obvious behaviors an agent could not infer from the schema.

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 description is long but well-organized with clear sections (Required, Conditionally required, Common optional, Less common) and front-loaded purpose. The price_schedule paragraph is somewhat verbose, but the structural delegation of advanced fields to protocol_reference avoids even more bloat. Every section earns its place given the 25-parameter complexity.

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?

For a highly complex tool with no output schema and no annotations, the description is remarkably complete: it covers conditional requirements, key-handling flow, trust-score side effects, payment validation, and the two-step capability confirmation edge case. Minor gaps include the absence of a full 200-success response shape (beyond claim_link) and no explicit error-case handling, but overall the burden is mostly satisfied.

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 description coverage is 0%, so the description compensates heavily: agent_id, capabilities (with weight limits), endpoint_url, protocol, settlement_rail, message_protocol, http_methods, price_schedule, and payment fields all receive meaningful semantics beyond bare names, including examples. Gaps remain: candidate_matches is never mentioned, capability_confirmations is only implied by the 202 flow, and the seven 'less common' fields are listed by name with semantics deferred to protocol_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?

The opening sentence 'Register a new AI agent (or human) with the Aidress trust registry' uses a specific verb and resource, and 'new' clearly distinguishes this creation tool from siblings like update_agent, verify_agent, and list_org_agents. The conditional requirement explanations (one agent per org_domain) further pin down its exact role.

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?

The description gives strong contextual usage guidance: it marks agent_id as required, explains when org fields become conditionally required (when endpoint_url is set), and explicitly routes follow-up actions to claim_bearer_key and protocol_reference('register_advanced_fields'). However, it never explicitly contrasts this tool with alternatives like update_agent or import_agent, so some when-not-to-use guidance is missing.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Aidress-ai/Aidress'

If you have feedback or need assistance with the MCP directory API, please join our Discord server