ChatPush MCP Server

Official

by ChatPush

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Set client name in chat

set_chat_client_name

Idempotent

Renames a ChatPush contact with its CRM client name so operators see a real name instead of a phone number; locate the conversation by phone or Telegram identifier.

Instructions

Rename a contact in the ChatPush web messenger, so operators see a person's real name instead of a phone number. The name is stored as the CRM client name of the conversation.

Find the conversation by phone, Telegram username or Telegram user ID — at least one is required. If the contact has both WhatsApp and Telegram conversations, both are renamed.

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

Input Schema

Name	Required	Description
`name`	Yes	New name for the contact, e.g. the customer name from your CRM.
`phone`	No	Contact phone number in international format.
`tdlib_user_id`	No	Contact's Telegram user ID.
`tdlib_username`	No	Contact's Telegram username.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 4, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context: the name is persisted as the CRM client name, and the rename fans out to both WhatsApp and Telegram conversations — a side effect an agent would not predict from the schema. It does not describe failure behavior when no conversation matches.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short paragraphs: the first front-loads purpose and outcome, the second carries the lookup constraint and multi-channel effect. No restated field names, no filler, nothing that could be cut without losing information.

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 mutation tool with no output schema, it covers what changes, what is stored, and the scope of the change. The remaining gap is what happens on no-match or partial-match (e.g., only Telegram exists) and whether the response reports which conversations were renamed.

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, but the description adds a real constraint the schema does not enforce — required only lists 'name', yet the description states at least one of phone/tdlib_user_id/tdlib_username must be supplied. It also clarifies that the identifiers locate the same contact rather than selecting distinct records.

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?

States a specific verb and resource ('Rename a contact in the ChatPush web messenger') plus the operator-facing outcome ('real name instead of a phone number'). No sibling tool touches contact naming, and the description makes the effect unambiguous without needing the schema.

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 a clear precondition — find the conversation by phone, Telegram username, or Telegram user ID, at least one required — and explains the cross-channel consequence when both WhatsApp and Telegram threads exist. It lacks explicit when-not-to-use guidance, but there is no competing sibling for this operation.

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