Skip to main content
Glama

Create a channel

create_channel
Idempotent

Create a channel on an agent or an app. On an agent: a cron or heartbeat channel that wakes it on a schedule, a webhook channel that lets callers outside Valet reach it, or an mcp channel that serves it as an MCP server; what the agent does when it fires is the prompt file channels/.md in its source. On an app: a webhook, cron, or heartbeat channel whose deliveries Valet posts to path in the app, so a private app takes webhooks and scheduled work without becoming public. Valet checks a webhook's signature before anything reaches the app, then posts the request as the sender sent it; a cron or heartbeat fire posts a small JSON body. Each delivery carries an X-Valet-Visitor token of kind channel and a delivery_key to treat as an idempotency key; return 2xx, and anything else retries for about a day. A webhook is signed by a secret you choose, because this never returns a secret value: set it with set_env_vars on the agent or app first, then pass its name as secret_name. A webhook without secret_name is refused. Creating a channel that already exists with the same kind and settings reports it and changes nothing; different settings are refused, so destroy it first. Slack and Telegram need a browser, so for them this gives the step to take and creates nothing. Requires connecting a Valet account.

Input Schema

NameRequiredDescriptionDefault
nameYesRequired. The agent's or app's name.
pathNoRequired for a channel on an app, and only there: the path in the app that handles each delivery, such as /webhooks/stripe. It starts with / and is not under /__valet/.
channelYesRequired. The new channel's name: lowercase letters, digits, and hyphens.
org_nameNoThe Valet organization the agent or app belongs to. Omit to use the organization the account joined first.
scheduleNoFor cron, a schedule such as 'weekdays at 9:00am' or 'every 30 minutes' or a five-field cron expression. For heartbeat, an interval between 30s and 24h such as '15m'. Not used by other kinds.
timezoneNoFor cron, an IANA timezone such as America/New_York. Omit for UTC.
secret_nameNoRequired for webhook. The name of an environment variable on this agent or app that holds the signing secret, set first with set_env_vars. Not used by other kinds.
channel_kindYesRequired. One of cron, heartbeat, webhook, mcp, slack, or telegram, from list_catalog_channels. An app takes webhook, cron, or heartbeat only. Slack and Telegram give the step to take instead of creating anything.
verify_schemeNoFor webhook, how the sender signs: hmac-sha256 (the default), static-token for a sender that cannot sign, stripe, svix, slack, or mercury. This tool creates signed webhooks only, so there is no way to turn verification off.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

With annotations already declaring non-destructive, idempotent and open-world, the description adds substantial non-obvious behavior: signature verification before delivery, X-Valet-Visitor and delivery_key headers, 2xx-else-retry-for-a-day, refusal of webhooks lacking secret_name, and the fact that the secret is never returned. These are operational facts an agent cannot infer from the annotations or schema.

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?

Front-loaded with purpose, then types, then delivery semantics, then failure modes — a sensible ordering with no filler sentences. It is a dense single paragraph, however, and the delivery/verification details could be split or bulleted to be scanned faster.

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?

Covers creation, idempotency, refusal modes, runtime delivery behavior and setup prerequisites for a 9-parameter mutating tool with no output schema. The only soft gap is what a successful call returns (channel record? delivery URL?), which is left implicit aside from the 'reports it' case for duplicates.

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 real meaning: it explains why secret_name exists (the tool never returns a secret), that an unsignable case exists but verification cannot be disabled, and ties channel_kind to list_catalog_channels. It stops short of documenting per-kind required combinations in one place, so it's a notch below the top.

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?

Opens with a specific verb+resource ('Create a channel on an agent or an app') and immediately decomposes the two target types into their allowed channel kinds. An agent can distinguish this from sibling operations like attach_channel or reauthorize_channel without opening a 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?

Explicitly states prerequisites (connect a Valet account, set the signing secret with set_env_vars before passing secret_name, get channel_kind from list_catalog_channels) and gives the alternative path when a channel already exists with different settings ('destroy it first'). Also carves out Slack/Telegram as not-creatable here, which is an exclusion, not just guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources