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

update_agent

Update an existing agent's profile fields. Only the provided attributes are changed; omitted information stays as is.

Instructions

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 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("") 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.

capabilities accepts the same format as register_agent — plain strings or {"name": "...", "weight": N} dicts.

payload_schema — semantic conventions for this agent's payloads. Dict with any of: currency (e.g. "USD"), date_format (e.g. "ISO8601"), quantity_unit (e.g. "individual_items"), weight_unit (e.g. "kg"). Only these four keys are accepted; unknown keys return 422. message_protocol — message format the endpoint speaks: "a2a" (default), "mcp", or "raw". Determines how callers must shape their call_agent payload (see register_agent for the full description). signup_help — link/instructions for callers to obtain their own credential, if your endpoint requires one (see protocol_reference("register_advanced_fields") for details). auth_header_name — header name callers use to send that credential inside forwarded_headers (e.g. "X-Api-Key", "Authorization"). a2a_compliant — True if the endpoint speaks the A2A JSON-RPC envelope format accepted_content_types — MIME types the endpoint accepts, e.g. ["application/json"]

pull_from_agent_id — SANDBOX ONLY; refreshes a sandbox draft from its paired live agent's current values. See protocol_reference("update_agent_advanced_fields").

price_schedule, payment_network, payment_pay_to, payment_asset — see register_agent; same fields, same rule (all three payment_* fields required together whenever price_schedule is set in this call).

Returns the updated trust object.

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
pull_from_agent_idNo
accepted_terms_formatNo
accepted_content_typesNo
Behavior5/5

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

With no annotations provided, the description fully bears the transparency burden. It discloses authentication requirements in detail, explains why per-call key parameters are absent, notes the sandbox-only constraint for pull_from_agent_id, specifies validation rules (unknown keys return 422), and states the return value. This is exemplary behavioral transparency for a mutation tool.

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: a two-sentence core behavior summary, followed by a clearly separated authentication block, and then a parameter-by-parameter breakdown. Every section adds necessary value for a tool with no annotations, though the auth section is lengthy and some formatting breaks could be tightened.

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?

Given the tool's complexity (23 parameters, no output schema, no annotations), the description is remarkably complete. It covers auth, parameter semantics, special validation rules, sandbox restrictions, cross-references to register_agent for shared fields, and the return value. It leaves little ambiguity for an agent attempting to use the tool correctly.

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 must compensate. It adds meaningful semantics for many parameters (e.g., agent_id immutability, contact_email's role, capabilities format, payload_schema allowed keys, message_protocol implications, and the payment_* rule). However, some parameters like org_name, protocol, specialty, and settlement_rail are left to inference from their names, so it does not fully cover all 23.

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 description clearly states the tool's function: 'Update an existing agent's profile fields' with specific behavior ('Only provided fields are changed; omitted fields remain unchanged'). This distinguishes it from sibling tools like register_agent and get_agent, and clearly identifies the resource being acted upon.

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?

It provides clear context for when to use the tool (updating existing agents) and emphasizes partial-update semantics. However, it does not explicitly name alternatives (e.g., 'use register_agent for new agents') or state exclusions, so it stops short of a 5.

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