Imported from zapier/connectors (apps/discord/SKILL.md). Install upstream with npx skills add zapier/connectors --skill discord. Copyright stays with the author (Elastic-2.0).

Discord

Agent-callable tools for a Discord server, running against the Discord API (https://discord.com/api/v10). The connector authenticates as a bot added to one or more servers: send and manage messages, start threads and forum posts, create and edit channels, manage members and roles, post through channel webhooks, and read the servers, channels, members, roles, and emojis an agent needs to resolve the ids those actions take. 29 scripts. Because a single bot can belong to many servers, every server-scoped tool takes an explicit guild_id (a server id), which you resolve with listGuilds.

Independent, unofficial connector for Discord. Not affiliated with, endorsed by, or sponsored by Discord. "Discord" is a trademark of its owner, used only to identify the service this connector works with.

When to use this

• An agent needs to send or manage messages — post to a channel, thread, or forum post, reply, edit or delete a message, add or remove reactions, or DM a user.
• An agent needs to manage threads and channels — start a forum post or standalone thread, create a channel, rename or re-topic one, and list channels or active threads.
• An agent needs to administer members and roles — list, search, or read members, add or remove roles, and list or create roles.
• An agent needs to read servers and resolve ids — list the bot's servers, read a server / user / member, list custom emojis, and post via channel webhooks under a custom identity.

Setup

This is an agentskills.io skill.

If the connector has not been installed as a skill yet, install it first with npx skills add zapier/connectors --skill discord (or your harness's own skill-install mechanism), then continue here. Installing the skill copies these files, not dependencies. Before running the CLI, a local MCP server, or zapier-sdk auth commands, run npm install --omit=dev here once. Importing the published package as a dependency in your own project instead? That npm install already resolves everything — see references/use-as-sdk.md.

Want the actual repo source instead — to browse references/, run this connector's tests, or hack on it? See README.md for a scoped git clone.

The connector runs on Node.js 22.18+. Pick the reference that matches how you're running it, and load it before doing anything else:

Scripts

All 29 scripts use the single connection discord (a bot token). Server-scoped tools take an explicit guild_id — resolve it with listGuilds first. Every other required id has a resolver: channel_id ← listChannels, user_id ← listMembers / searchMembers, role_id ← listRoles, custom emoji ← listEmojis, message_id ← listChannelMessages, and webhook_id / webhook_token ← createWebhook / listChannelWebhooks.

Disambiguation & refusals

This connector resolves names to ids, then writes. Two situations trip up an action-biased agent — handle both before you write.

Before writing to a record you looked up by name — count how many returned records match the name the user gave exactly (case-insensitive). Common collisions: a member looked up via searchMembers / listMembers (two people share a display name), or a channel picked out of listChannels (two channels named general).

• One exact match (even among other fuzzy hits) → act on it. Don't ask for a confirmation you don't need.
• Two or more that tie → stop. List the tied candidates with a distinguishing field (id + username / nickname for members, id + parent_id / type for channels) and ask which one the user means. Never pick one yourself and write against it, and never write to all of them.

Before fulfilling a request, check that a script actually does it. This connector deliberately does not:

• Moderate members — no bans, kicks, or timeouts. There is no tool for it; removing a role (removeMemberRole) is not a substitute.
• Upload files or attachments, join voice, or subscribe to events / triggers (new-message, new-member, reactions as they happen). None of these have a tool here.

If asked for any of these, say plainly it's unsupported and stop. Don't substitute a different script and report success for an action you didn't perform.

Every server-scoped tool takes an explicit guild_id because one bot token can span many servers — resolve it with listGuilds first. Individual actions additionally require the bot to hold the matching Discord permission in the target server (Manage Messages / Roles / Channels / Webhooks) and, for role changes, a role positioned above the target role — these surface as runtime permission errors, not connection errors, so a failure here doesn't mean the connection is broken.

Auth

Every shape passes auth as one connection selector, not the secret — a [<resolver>:]<value> string. Every connector accepts zapier:<connection-id> (Zapier-managed auth — routes through Zapier's auth, retries, and governance layer); some also accept one or more direct-token resolvers (naming and count vary per connector) — check this connector's own resolvers rather than assuming. The <resolver>: prefix is optional; a bare value goes to the first resolver that claims it — a UUID-shaped bare value always claims zapier:. Each script declares the connections it needs and the resolvers each accepts. The exact syntax for passing a connection (and how to see this connector's resolver list) differs by shape — see the reference you loaded above.

Checking what's already configured first? Don't dump environment values to do it — env or env | grep <name> prints the value along with the name, leaking a live credential into the transcript if one is set. Check names only (env | cut -d= -f1 | grep -i <name>) or test a known name directly ([ -n "$VAR_NAME" ]).

No connection yet? Pick one — and follow the reference's own flow to obtain it; never just ask the user for a connection id or token as if they already have one memorized:

Output format

Every script returns a { data, meta } envelope:

• data — the script's result (the shape its outputSchema declares; see the reference you loaded above for how to inspect a script's exact schema in your shape).
• meta.outputDataValidation — what validating data did:
  • { skipped: false, droppedPaths: null } — validated, nothing removed.
  • { skipped: false, droppedPaths: [...], instruction } — validated, but those paths were stripped from data: fields the script returned from the API that the outputSchema doesn't declare. If you need them, re-run with output validation skipped.
  • { skipped: true } — validation was bypassed; data is the raw, unchecked script output.

Reading dropped fields / skipOutputDataValidation. To receive the raw, unvalidated result, opt out of output validation (the exact syntax differs by shape — see the reference you loaded above). Input validation is never skipped.

Trimming the result / filterOutputData. To shrink a large result down to the fields you need, pass a jq expression that post-processes data (again, exact syntax per shape). The jq runs against data only, NOT the { data, meta } envelope, so write it rooted at data (run the script's --help — or your shape's equivalent — to see its output schema). The transformed value replaces data, meta is preserved, and the result is NOT re-validated against the output schema.

References

Load the matching reference file before working in that area: