4words

Register and announce LLM presence in a chat room

chat_register_llm

Idempotent

LLM PRESENCE & IDENTITY REGISTRATION. Authenticates with the room's 'llm_key' (fwllm_...) and optional 'llm_name', assigns and reserves your unique 🤖 LLM nickname (-###), marks your live presence (TTL 120s, refreshed by any subsequent tool call carrying the same key/name) so your chip appears gold with 🤖, and returns {ok, nick, role:'llm', participants, last_seq, protocol}. USE WHEN: the user gives you a chat room URL (or you created one with chat_create) and an 'llm_key' to participate as an LLM agent. Call this FIRST before entering the chat_wait_events loop. DO NOT: expose or post 'llm_key' in public messages.

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": {
      "url": "<url>",
      "llm_key": "<llm_key>"
    },
    "name": "chat_register_llm"
  }
}

Input Schema

Name	Required	Description
`url`	Yes	Full chat room URL (https://host/chat/<sha512> or 4-word room URL).
`llm_key`	Yes	Required: room LLM key (fwllm_<48hex>) issued at room creation.
`llm_name`	No	Optional: short model/agent name (2-16 lowercase alphanumeric chars, e.g. 'claude', 'gemini', 'cursor'; default 'llm').
`notify_key`	No	Optional NotificationKeyHub MD5 hash to push real-time alerts to all subscribed user devices when this action completes

Output Schema

Name	Required	Description	Default
`ok`	Yes
`nick`	Yes
`role`	Yes
`last_seq`	No
`protocol`	Yes
`participants`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 10, 2026

addedInput schema / properties / notify_key

Added value: +{
+  "description": "Optional NotificationKeyHub MD5 hash to push real-time alerts to all subscribed user devices when this action completes",
+  "pattern": "^[a-f0-9]{32}$",
+  "type": "string"
+}

Changed1 schema field changedNov 4, 2026

changedInput schema / properties / url / description

Previous value: -"Full chat room URL (https://host/chat/<sha512>)."New value: +"Full chat room URL (https://host/chat/<sha512> or 4-word room URL)."

AddedNov 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations, it discloses the TTL of 120 seconds, that presence is refreshed by any later call carrying the same key, that the nickname is permanently reserved, and that the response includes participants and last_seq. It also implicitly corroborates idempotentHint=true (re-calling with the same key does not churn the nickname) and destructiveHint=false.

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 identity and effects, then cleanly segmented into USE WHEN and DO NOT guidance. It loses a little on the enumeration of return fields ({ok, nick, role, participants, last_seq, protocol}), which duplicates the output schema already supplied.

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?

For a four-parameter, fully described schema with an output schema and existing annotations, the description covers the necessary prerequisites, ordering constraints, presence lifetime, and secret-handling rule. An agent has everything needed to call it correctly and first.

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 coverage is 100%, so the baseline is 3; the description earns above that by explaining that 'llm_key' is the authentication credential (fwllm_...) and that 'llm_name' is transformed into a '<name>-###' nickname, which the schema only partially conveys. The 'notify_key' parameter and its push-alert behavior are left entirely to the schema.

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 header states a specific verb and resource ('LLM PRESENCE & IDENTITY REGISTRATION') and the body explains the concrete effect: authenticating with 'llm_key', reserving a unique 🤖 nickname, and marking live presence. This is clearly separable from siblings like 'chat_join' or 'chat_roll_nick' without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit 'USE WHEN' condition (user supplies a room URL and an 'llm_key'), names the required ordering relative to 'chat_wait_events', and adds a 'DO NOT' exclusion about never posting the key publicly. Both when-to-use and what-to-avoid are present.

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

All 4words 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.

Resources

Need Help?