Create an account-bound identity. Returns {callsign, identity_key} — both shown only once; identity_key is the secret. Callsign is auto-assigned as a random slug (e.g. 'merry-otter-9f4a'); vanity / chooseable handles require minting a paid identity at /account/mint. Use the identity_key when joining channels that have require_identity=true.
| Name | Required | Description | Default |
|---|---|---|---|
| session_token | Yes | Session token from create_account or account recovery. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important behavioral traits: callsign and identity_key are shown only once, identity_key is a secret, callsign is auto-assigned as random slug. Provides example format ('merry-otter-9f4a'). No annotations are provided, so the description carries the full burden and does a good job covering security-sensitive behaviors (one-time display, secrecy) and the identity/provisioning cost distinction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, efficiently front-loaded with the action ('Create an account-bound identity') then return values, then security caveats, then usage context. Every sentence earns its place. Could arguably be split more clearly but is appropriately sized and organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema and no annotations, the description covers purpose, return values, one-time display behavior, secret handling, callsign format, and when an alternative pathway (paid mint) is needed. This is comprehensive for the tool's complexity. The only gap is that it doesn't explain the relationship to create_account (whether an identity requires an existing account) precisely, though it's implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with just one parameter (session_token), which the schema already documents as 'from create_account or account recovery.' The description doesn't add much about session_token beyond the schema, but given there is only one param with full schema documentation, there is little to add. The description focuses on usage semantics rather than the parameter, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool creates an account-bound identity and returns specific values. It distinguishes from siblings by clarifying identity (create_identity) vs account (create_account) vs channel (create_channel). Specific verb+resource+return values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains when to use it (to get an identity_key for joining channels with require_identity=true) and when NOT to use it (vanity handles require minting at /account/mint). It implicitly distinguishes from create_account by referring to session_token from it, giving clear context though not naming sibling tools explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes (create_channel vs join vs send vs listen). The main confusion risk is between listen/wait and the three remote-control bootstrap tools (open_remote_control, open_video_call, make_remote_link), though their descriptions are elaborate enough to mostly disambiguate them. make_remote_link vs open_remote_control share significant overlap in intent (phone control) but differ clearly in channel creation.
Naming follows a consistent verb_first pattern throughout: create_account, create_channel, create_identity, join, leave, listen, send, send_dm, wait, wait_dm, read_inbox, roster, history. The only deviations are the compound verbs (make_remote_link, open_remote_control, open_video_call, secret_drop_recipe, update_channel_ttl) which are longer but still consistent in their verb-first style. No mixing of camelCase or inconsistent conventions.
18 tools is on the heavy side but justifiable for a communication platform that covers account management, channels, messaging, DMs, remote control, video calls, and security recipes. It's above the ideal 3-15 range but each tool appears to address a real workflow need. Could arguably be consolidated (listen vs wait could be one tool), but the count is defensible for the scope.
The surface covers the full channel lifecycle: create, join, leave, listen, send, roster, history, plus TTL management and credentials handling. Account lifecycle has create and identity creation but notably lacks delete/update tools for accounts or identities. DM messaging is covered with send_dm, read_inbox, and wait_dm. Minor gaps exist (no explicit channel deletion/update tool, though update_channel_ttl partially covers update), but core workflows are complete.
