Skip to main content
Glama
Sign In

RelayLink

by ai.relaylink
OverviewDiscussionsAdmin

Rename a contact

rename_contact
Idempotent

Set what the user calls one of their accepted contacts — "call Billy12399d@gmail.com Billy" — so "@ Billy" and toContact "Billy" reach that person from then on. The nickname is private to the user's own list: the contact never sees it, cannot set it, and it must not appear in anything sent to them — use it when speaking to the user and as toContact, and write packages in words the recipient would recognise. Pass an empty nickname to clear one. Only accepted contacts can be renamed; a name that is not one fails exactly like a name nobody has.

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": {
      "contact": "<contact>"
    },
    "name": "rename_contact"
  }
}

Input Schema

NameRequiredDescriptionDefault
contactYesWho to rename: their email address, their current name in list_contacts, or the nickname they already have.
nicknameNoWhat the user wants to call them, at most 40 characters and no '@'. Empty clears the nickname.
shareWithThemNotrue if the user has said this contact may see what they call them, which lets the nickname appear in packages sent to them. Ask the user and pass their answer — never assume one. Every rename resets it to false, so pass the nickname alongside it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

With annotations already covering mutation and idempotency, the description adds meaningful behavioral context: the nickname is private, the contact can never see it, it must not appear in sent content, empty clears it, and invalid names fail indistinguishably from unknown names. It does not mention that every rename resets shareWithThem, but that is fully documented in 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 front-loaded with the core effect and an example, then adds privacy and eligibility constraints. It is dense but every sentence is relevant; the 'write packages in words the recipient would recognise' clause is the only slightly tangential piece.

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 three-parameter, fully documented mutation tool with annotations and no output schema, the description covers purpose, privacy semantics, clearing, eligibility, and failure behavior. The only minor gap is not restating the shareWithThem reset rule, which the schema already explains.

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 100%, so the schema already documents contact, nickname, and shareWithThem in detail. The description reinforces the clearing behavior and gives a nickname example, but adds no parameter-level meaning beyond what the schema provides; baseline 3 is appropriate.

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 states a specific verb and resource ('Set what the user calls one of their accepted contacts'), and its example clarifies the exact effect on handles and toContact. It is unmistakably distinct from siblings like set_my_name or tag_contact.

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 clearly says when to use the nickname ('use it when speaking to the user and as toContact') and constrains eligibility ('Only accepted contacts can be renamed'). It lacks an explicit comparison to alternatives, but the usage context is clear.

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

All RelayLink toolsInspect
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.

Resources