DEBYKO

DEBYKO connect a channel

agent_channel_connect

Destructive

Connects a channel for Agent alerts. {kind: "telegram"} returns a one-time link to @debyko_bot (it works once, for 10 minutes) and the steps; {kind: "email"} emails a confirmation link to the account's address; {kind: "webhook", url} adds the webhook, sends it a test message and returns its status. First ask the user which they want, and for a webhook its public https:// address. Give the user next as numbered steps, link exactly as returned; after they say they pressed Start or confirmed, check with agent_channels. The webhook's signing key is never returned here: next says where the user gets it. Not counted on your key. Use this when the account has no channel for an alert, or the user wants another one; to see the channels it has use agent_channels.

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

Input Schema

Name	Required	Description
`url`	No	With `webhook`: the receiver's public https:// address. Not used with `telegram`.
`kind`	Yes	`telegram`: a link the user opens to link their chat. `email`: the account's address. `webhook`: an https:// receiver of the user's.
`name`	No	With `webhook`: a name for it; the host of the address when left out.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 22, 2026

changedInput schema / properties / kind / description

Previous value: -"`telegram`: a link the user opens to link their chat. `webhook`: an https:// receiver of the user's."New value: +"`telegram`: a link the user opens to link their chat. `email`: the account's address. `webhook`: an https:// receiver of the user's."

changedInput schema / properties / kind / enum

Previous value: -[
-  "telegram",
-  "webhook"
-]New value: +[
+  "telegram",
+  "email",
+  "webhook"
+]

Changed1 schema field changedOct 13, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "chats": {
+          "type": "array"
+        },
+        "kind": {
+          "const": "telegram",
+          "type": "string"
+        },
+        "next": {
+          "type": "string"
+        },
+        "status": {
+          "const": "linked",
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    {
+      "patternProperties": {
+        "^(?:link|expires_at|next)$": {
+          "type": "string"
+        }
+      },
+      "properties": {
+        "kind": {
+          "const": "telegram",
+          "type": "string"
+        },
+        "status": {
+          "const": "pending",
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    {
+      "patternProperties": {
+        "^(?:id|name|url|next)$": {
+          "type": "string"
+        }
+      },
+      "properties": {
+        "kind": {
+          "const": "webhook",
+          "type": "string"
+        },
+        "status": {
+          "const": "added",
+          "type": "string"
+        },
+        "test": {
+          "type": "object"
+        }
+      },
+      "type": "object"
+    }
+  ],
+  "type": "object"
+}

AddedOct 13, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing per-kind side effects the agent could not otherwise know: the telegram link is single-use and expires in 10 minutes, the email path mails a confirmation link to the account address, and the webhook path sends a live test message to the user's endpoint. It also states that the webhook signing key is deliberately not returned here and that the call is not counted against the user's key — quota context absent from annotations.

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?

Dense but front-loaded: the kind-specific outcomes come first, then the interaction instructions, then the exclusion routing to `agent_channels`. The mid-paragraph switch from behavioral description to user-facing scripting ('Give the user `next` as numbered steps, link exactly as returned') is slightly crowded against the return-value details, but no sentence is filler.

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?

An output schema exists, so return shape need not be re-explained, and the description still covers the operational gaps an agent needs: which kind to ask for, that the link must be relayed verbatim, the 10-minute window, where the signing key is obtained instead, and how to confirm success. Nothing needed to invoke it correctly 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?

Schema coverage is already 100%, so the schema documents `kind`, `url`, and `name` fully; the description nonetheless adds cross-parameter meaning by tying each `kind` value to its outcome ('{kind: "webhook", url} adds the webhook, sends it a test message'). It stops short of explaining `name` in prose, leaving that 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?

States a specific verb and resource ('Connects a channel for Agent alerts') and then enumerates the three kinds with exactly what each returns: a one-time telegram link, an email confirmation link, or a webhook added and test-messaged. It is clearly distinguishable from the sibling `agent_channels`, which is named as the read/inspect counterpart.

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?

Gives both sides of the routing decision: 'Use this when the account has no channel for an alert, or the user wants another one; to see the channels it has use `agent_channels`.' It also prescribes the interaction sequence (ask which kind first, collect the webhook URL) and the follow-up step (verify via `agent_channels` after the user presses Start).

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

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