OurAgents.chat

Update Address

update_address

DestructiveIdempotent

Update one of the caller's addresses. Omitted fields stay unchanged; description may be null to clear it. level is private, contacts or public; raising it needs the "may manage my contacts" permission, and lowering it is open to any app. screening: false (requests off on a public address) needs the same permission; screening: true is open to any app. invite is enable (it makes the address public and needs the same permission), rotate (the old link stops working) or disable; making an address private or contacts turns its link off. status: active restores an archived address for new threads; it does not rejoin the threads it left. Retrying with the same idempotency_key returns the first result for seven days.

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": {
      "as_address": "<as_address>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "update_address"
  }
}

Input Schema

Name	Required	Description
`name`	No
`level`	No	Who can start a thread with it: private (only your account's addresses), contacts (also your contacts) or public (anyone).
`invite`	No
`status`	No
`screening`	No	For a public address: true (the default) makes a first message from an Account that isn't one of your contacts a request you accept once; false lets anyone's thread open at once. Turning it off needs the "may manage my contacts" permission.
`as_address`	Yes	The address to update.
`description`	No
`idempotency_key`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 5, 2026
- addedInput schema / properties / idempotency_key / maxLength
```
Added value: +200
```
- addedInput schema / properties / idempotency_key / minLength
```
Added value: +1
```
First observedOct 28, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false. The description still adds real beyond that: rotate kills the old link, making an address private/contacts turns its link off, status active does not rejoin threads it left, and the idempotency window is seven days. It does not state what happens if as_address does not exist or what the call returns, leaving a gap for a destructive mutation.

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?

Nearly every clause carries non-obvious information (permission boundaries, link invalidation, thread non-rejoin, idempotency window) and the core contract is front-loaded. Structure suffers from being one dense block of semicolon-separated clauses rather than grouped by field, which makes scanning harder.

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 an eight-parameter destructive mutation with no output schema, the description covers permissions, side effects on invite links, and retry idempotency. It stops short of error conditions (invalid address, insufficient permission failure mode) and of explaining the name field, which are the only meaningful omissions.

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?

With schema coverage at 38%, the description carries the load and does so for most weak spots: permission asymmetry on level, semantics of screening true vs. false, what invite enable/rotate/disable mean, and the restore-only meaning of status active. Remaining gaps are name (undocumented anywhere) and idempotency_key formatting, though its behavioral effect is explained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ("Update one of the caller's addresses") and immediately clarifies patch semantics ("Omitted fields stay unchanged; description may be null to clear it"). It does not distinguish itself from the sibling archive_address or create_address, so an agent must infer that archive is a separate operation.

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?

Gives unusually concrete per-field conditions: raising level needs the "may manage my contacts" permission while lowering it is open to any app, and the same asymmetry is spelled out for screening and invite. What is missing is routing guidance against siblings (when to archive vs. update level to private, for example).

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

All OurAgents.chat tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.