Tulina

telegram_act

Destructive

⚠️ SENDS a TELEGRAM message via Unipile, from the person's own account — it leaves at once, there is no draft. Reading is telegram.

op:

"send" (default): sends text. chat_id → replies in an existing thread, 1-to-1 or group (from telegram(op="list")); otherwise recipient_id → opens a new thread with that contact.

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

Input Schema

Name	Required	Description	Default
`op`	No		send
`_org`	No	Org (id) de CET APPEL. `oto_list_orgs()`.
`text`	Yes
`_group`	No	Équipe (id) de CET APPEL, sous son org parente.
`_run_id`	No	OBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
`chat_id`	No
`_account`	No	Compte à OPÉRER quand plusieurs existent. `oto_identity(op='list')`.
`_project`	No	Projet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
`_instance`	No	Instance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
`recipient_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the safety profile is covered structurally; the description still adds real value by warning that the message "leaves at once, there is no draft" and that it is sent from the person's own identity. It stops short of describing failure modes, delivery/rate limits, or what happens if the recipient is not connected on Unipile.

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 warning and irreversibility constraint are front-loaded, and both paragraphs are dense with information and free of filler. Minor redundancy: the `op` bullet enumerates only "send", which the schema already fixes as a const with a default.

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 10-parameter, destructive, no-output-schema mutation tool, the definition covers the essentials an agent needs: it is irreversible, it is sent as the user, and how to choose the target. It could add what a successful call returns (message id / thread id) or what error means the contact cannot be reached, but nothing required for correct invocation is missing.

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 60% schema coverage, the description compensates for the two genuinely ambiguous business parameters: it explains that `chat_id` targets an existing thread (and points to `telegram(op="list")` as the source) while `recipient_id` creates a new thread. The remaining `_org`/`_group`/`_run_id`/`_account`/`_project`/`_instance` plumbing is already documented in the schema, so no further compensation is needed.

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 gives a specific verb and resource ("SENDS a TELEGRAM message via Unipile") and immediately distinguishes itself from the sibling `telegram`, which is the reading tool. The delivery channel (person's own account, no draft) is stated up front rather than buried.

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 explicitly names the alternative for the read case ("Reading is `telegram`") and spells out the two mutually exclusive addressing paths: `chat_id` for replying in an existing 1-to-1 or group thread, `recipient_id` for opening a new thread. The agent has no inference left to make about which parameter selects which behavior.

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

All Tulina 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?