coilyco-gaming/sirens-echo

Watch

Explore: let Echo invoke Discord apps, instead of maintaining an MCP per media service #485

New issue

Closed

opened 2026-08-13 14:24:24 +00:00 by coilyco-ops · 4 comments

coilyco-ops commented

2026-08-13 14:24:24 +00:00

Member

The idea

Raised by Kai, 2026-08-13, while reviewing the gaming and entertainment MCP shortlist. Recorded by Delphi (design seat, standing in for exec). Parked deliberately — Kai said "let's get into that later." Filed so it is not lost, and so the first question is already identified when it is picked up.

we dont need a spotify MCP if what we can get is giving sirens echo the ability to invoke discord apps of various kinds?

Why it is a good instinct

Discord already hosts a media ecosystem — Spotify integration, Watch Together, activities. If Echo can reach those, the community gets media features without Coilyco maintaining a server per service.

That matters given what coilyco-bridge/deploy#418 found: the gaming and entertainment MCP field is overwhelmingly single-author community projects, each one a dead-repo risk and a credential to hold. A Discord-native path trades a growing pile of small dependencies for one platform integration.

It also fits where the members already are. A Spotify MCP lets Echo talk about music; a Discord app integration could let the channel play it together. Those are different products, and the second is closer to a community space.

⚠️ Verify this first — it may be blocked at the platform level

Discord has historically not allowed bots to invoke other bots' application commands. Before any design work, someone needs to establish what is actually possible for a bot account:

Can a bot trigger another application's slash command? (Believed no — verify.)
Can a bot launch or manage an Activity in a voice channel?
Is there a supported integration path that is neither of those?
Whatever is possible — is it within Discord's terms, or only technically achievable? An unofficial technique is not an option for a bot in a real community.

If the answer is "not supported," this issue closes and the Spotify and YouTube questions go back to being MCP questions. That check is cheap and it gates everything else here, so it should happen before any scoping.

Blocks a decision downstream

Kai named YouTube and Spotify as gaps in the roster. Per the note on 418, do not scope a Spotify MCP until this is answered — the work may be redundant.

If it turns out to be possible

Design questions that would then need answers, none of them settled:

Which apps, and who decides? An allowlist is the obvious start.
Who may ask Echo to invoke one? This is a capability gate, and Kai ruled in #230 that Discord roles adjust content posture but grant no tool access — so gating on role would be a new kind of authority and needs its own decision.
Invoking an app is an action in a shared space, not a reply to one person. Starting playback affects everyone in the channel. Measured against the blast-radius line in #179, that touches tier 3, community harm — reversible, but it lands on people who did not ask.
Does it appear in the tool disclosure footer (#385)? It should — an invocation is an action-claim and needs a receipt.

Part of the broader question Kai opened about Echo becoming a fully featured media, entertainment and community space. Roster context: coilyco-bridge/deploy#418. Scope precedent: #229.

## The idea Raised by Kai, 2026-08-13, while reviewing the gaming and entertainment MCP shortlist. Recorded by Delphi (design seat, standing in for exec). **Parked deliberately — Kai said "let's get into that later."** Filed so it is not lost, and so the first question is already identified when it is picked up. > we dont need a spotify MCP if what we can get is giving sirens echo the ability to invoke discord apps of various kinds? ### Why it is a good instinct Discord already hosts a media ecosystem — Spotify integration, Watch Together, activities. **If Echo can reach those, the community gets media features without Coilyco maintaining a server per service.** That matters given what https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/418 found: the gaming and entertainment MCP field is overwhelmingly **single-author community projects**, each one a dead-repo risk and a credential to hold. A Discord-native path trades a growing pile of small dependencies for one platform integration. It also fits where the members already are. A Spotify MCP lets Echo *talk about* music; a Discord app integration could let the channel *play it together*. Those are different products, and the second is closer to a community space. ### ⚠️ Verify this first — it may be blocked at the platform level **Discord has historically not allowed bots to invoke other bots' application commands.** Before any design work, someone needs to establish what is actually possible for a bot account: - Can a bot trigger another application's slash command? *(Believed no — verify.)* - Can a bot launch or manage an Activity in a voice channel? - Is there a supported integration path that is neither of those? - Whatever is possible — is it **within Discord's terms**, or only technically achievable? An unofficial technique is not an option for a bot in a real community. **If the answer is "not supported," this issue closes and the Spotify and YouTube questions go back to being MCP questions.** That check is cheap and it gates everything else here, so it should happen before any scoping. ### Blocks a decision downstream Kai named **YouTube and Spotify** as gaps in the roster. Per the note on 418, **do not scope a Spotify MCP until this is answered** — the work may be redundant. ### If it turns out to be possible Design questions that would then need answers, none of them settled: - Which apps, and who decides? An allowlist is the obvious start. - Who may ask Echo to invoke one? This is a capability gate, and Kai ruled in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/230 that Discord roles adjust **content posture** but grant **no tool access** — so gating on role would be a new kind of authority and needs its own decision. - Invoking an app is an **action in a shared space**, not a reply to one person. Starting playback affects everyone in the channel. Measured against the blast-radius line in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/179, that touches tier 3, community harm — reversible, but it lands on people who did not ask. - Does it appear in the tool disclosure footer (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/385)? It should — an invocation is an action-claim and needs a receipt. ### Related Part of the broader question Kai opened about Echo becoming a fully featured media, entertainment and community space. Roster context: https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/418. Scope precedent: https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/229.

coilyco-ops referenced this issue

2026-08-13 14:28:20 +00:00

sirens echo should have harness level enforcement of the type of content it will reply to, call it content classifier #227

coilyco-ops commented

2026-08-13 14:53:03 +00:00

Author

Member

Investigated — the Spotify hypothesis does not hold, but the issue is not a dead end

Delphi (design seat, standing in for exec). 2026-08-13, at Kai's request. Answers the blocking platform question.

Path 1 — invoking another bot's slash commands: NO

Discord does not allow bots to trigger application commands. Confirmed across multiple independent sources, and it is a deliberate API design constraint rather than a gap.

The observed behaviour when people try: a bot sending /play something posts it as ordinary text. It is not interpreted as a command, by anything. So there is no partial or degraded version of this — it simply does not work.

This closes the specific idea in the issue title. Echo cannot drive another bot.

Path 2 — Discord Activities: probably yes, and the sources conflict

Two mechanisms surfaced, and they disagree:

Activity invite links. A bot creates an invite to an embedded application in a voice channel. This is the long-standing approach and there are working public bots doing it today, so it is real.
LAUNCH_ACTIVITY interaction callback. Discord's own documentation describes activities as launchable "by any user in a channel or from a bot with the LAUNCH_ACTIVITY interaction callback" — while a separate source states flatly that bots cannot launch or participate in Activities. My read is that LAUNCH_ACTIVITY is the newer sanctioned mechanism and the contradicting claim is either stale or about bots joining rather than launching.

Not resolved from secondary sources. Whoever picks this up must read Discord's current developer documentation directly before designing anything. I am reading blog posts; this needs the primary docs.

Note the shape if it does work: LAUNCH_ACTIVITY is an interaction callback — a bot fulfilling a user's request, not acting spontaneously. That fits Echo's reactive-only posture exactly (#205), which is a good sign rather than a coincidence.

The finding that matters: this does not give Echo music

Activities are embedded web apps — games, Watch Together. Discord's Spotify integration is a user account link, not an app that can be invoked.

So even in the most favourable reading of path 2:

✅ Echo could potentially start an Activity — a game, Watch Together
❌ Echo cannot control a member's Spotify
❌ Echo cannot invoke a music bot's commands

The premise in this issue — "we don't need a spotify MCP if we can invoke discord apps" — is answered: no. The Discord path delivers Activities, not music control.

Where that leaves Spotify and YouTube

Back to the auth-model finding on coilyco-bridge/deploy#418. Spotify playback needs per-user OAuth, which is structurally wrong for a bot serving a shared channel — every member would have to authorise Echo individually. That was true before this investigation and remains the binding constraint.

Honest bottom line: Echo can talk about music, and cannot play it. MusicBrainz is keyless and covers the talking-about-it half well.

YouTube is unblocked and always was — the RSS path in coilyco-bridge/deploy#463 needs nothing from Discord.

The 418 hold is lifted. Spotify and YouTube are no longer waiting on this issue.

What this issue should become

The original framing is closed. What survives is genuinely different and worth keeping:

Can Echo launch Discord Activities on request? Not a Spotify workaround — a community-space feature in its own right. A member asks Echo to start Watch Together or a game, and it does.

That fits the identity Kai set (#227): participating in the space rather than only answering. And it stays reactive.

If it is pursued, the design questions from the issue body still apply — allowlist of which activities, who may ask, and the tier-3 consideration from #179 that launching an activity lands on everyone in the channel, not just the person who asked. It should also appear in the tool disclosure footer (#385) — an invocation is an action and needs a receipt.

Recommend retitling to reflect the surviving scope, so nobody reads the current title and concludes music is coming.

Sources: discord.py discussion · Discord apps overview · voice activities bot · activities bot · Embedded App SDK

## Investigated — the Spotify hypothesis does not hold, but the issue is not a dead end Delphi (design seat, standing in for exec). 2026-08-13, at Kai's request. **Answers the blocking platform question.** ### Path 1 — invoking another bot's slash commands: **NO** **Discord does not allow bots to trigger application commands.** Confirmed across multiple independent sources, and it is a deliberate API design constraint rather than a gap. The observed behaviour when people try: a bot sending `/play something` **posts it as ordinary text**. It is not interpreted as a command, by anything. So there is no partial or degraded version of this — it simply does not work. **This closes the specific idea in the issue title.** Echo cannot drive another bot. ### Path 2 — Discord Activities: **probably yes, and the sources conflict** Two mechanisms surfaced, and they disagree: - **Activity invite links.** A bot creates an invite to an embedded application in a voice channel. This is the long-standing approach and **there are working public bots doing it today**, so it is real. - **`LAUNCH_ACTIVITY` interaction callback.** Discord's own documentation describes activities as launchable *"by any user in a channel or from a bot with the LAUNCH_ACTIVITY interaction callback"* — while a separate source states flatly that bots cannot launch or participate in Activities. My read is that `LAUNCH_ACTIVITY` is the newer sanctioned mechanism and the contradicting claim is either stale or about bots *joining* rather than *launching*. **Not resolved from secondary sources. Whoever picks this up must read Discord's current developer documentation directly** before designing anything. I am reading blog posts; this needs the primary docs. Note the shape if it does work: `LAUNCH_ACTIVITY` is an **interaction callback** — a bot fulfilling a user's request, not acting spontaneously. That fits Echo's reactive-only posture exactly (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/205), which is a good sign rather than a coincidence. --- ## The finding that matters: this does not give Echo music **Activities are embedded web apps** — games, Watch Together. **Discord's Spotify integration is a user account link, not an app that can be invoked.** So even in the most favourable reading of path 2: - ✅ Echo could potentially start an Activity — a game, Watch Together - ❌ Echo cannot control a member's Spotify - ❌ Echo cannot invoke a music bot's commands **The premise in this issue — *"we don't need a spotify MCP if we can invoke discord apps"* — is answered: no.** The Discord path delivers Activities, not music control. ### Where that leaves Spotify and YouTube Back to the auth-model finding on https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/418. **Spotify playback needs per-user OAuth**, which is structurally wrong for a bot serving a shared channel — every member would have to authorise Echo individually. That was true before this investigation and remains the binding constraint. **Honest bottom line: Echo can talk about music, and cannot play it.** MusicBrainz is keyless and covers the talking-about-it half well. **YouTube is unblocked and always was** — the RSS path in https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/463 needs nothing from Discord. **The 418 hold is lifted.** Spotify and YouTube are no longer waiting on this issue. --- ## What this issue should become The original framing is closed. What survives is genuinely different and worth keeping: **Can Echo launch Discord Activities on request?** Not a Spotify workaround — a community-space feature in its own right. A member asks Echo to start Watch Together or a game, and it does. That fits the identity Kai set (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/227): participating in the space rather than only answering. And it stays reactive. **If it is pursued, the design questions from the issue body still apply** — allowlist of which activities, who may ask, and the tier-3 consideration from https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/179 that launching an activity lands on everyone in the channel, not just the person who asked. It should also appear in the tool disclosure footer (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/385) — an invocation is an action and needs a receipt. **Recommend retitling to reflect the surviving scope**, so nobody reads the current title and concludes music is coming. Sources: [discord.py discussion](https://github.com/Rapptz/discord.py/discussions/9090) · [Discord apps overview](https://docs.discord.com/developers/quick-start/overview-of-apps) · [voice activities bot](https://github.com/DenverCoder1/discord-voice-activities-bot) · [activities bot](https://github.com/advaith1/activities) · [Embedded App SDK](https://support-dev.discord.com/hc/en-us/articles/21204423970071-Introducing-the-Embedded-App-SDK)

coilyco-ops commented

2026-08-13 14:56:49 +00:00

Author

Member

Verified against Discord's primary docs — corrects my previous comment

Delphi (design seat, standing in for exec). 2026-08-13. Kai asked for the actual documentation. This supersedes the Activities section of my comment above, which was based on blog summaries and got the mechanism wrong.

The contradiction is resolved: bots can launch Activities

Discord's own documentation, verbatim:

They're built with the Embedded App SDK and can be launched by any user in a channel or from a bot with the LAUNCH_ACTIVITY interaction callback.

The source claiming bots cannot launch Activities was wrong. But the mechanism is narrower than I implied.

⚠️ `LAUNCH_ACTIVITY` only launches the app's own Activity

Interaction callback type table, verbatim:

| LAUNCH_ACTIVITY | 12 | Launch the Activity associated with the app. Only available for apps with Activities enabled |

"The Activity associated with the app." Same scope on the command side — PRIMARY_ENTRY_POINT (command type 4) "represents the primary way to invoke an app's Activity", with handlers APP_HANDLER (1) and DISCORD_LAUNCH_ACTIVITY (2). Enabling Activities auto-creates a "Launch" command.

So this path requires Echo to have an Activity — an embedded web app built with the Embedded App SDK. That is building a product, not integrating with one. It does not let Echo launch Watch Together or someone else's game.

I said Echo "could potentially start an Activity — a game, Watch Together" via this callback. That was incorrect.

✅ The mechanism that does work: invite creation

POST /channels/{channel.id}/invites, verbatim:

the id of the embedded application to open for this invite, required if target_type is 2, the application must have the EMBEDDED flag

Requirement	Value
Endpoint	`POST /channels/{channel.id}/invites`
`target_type`	`2` (embedded application)
`target_application_id`	the target app's id
Permission	`CREATE_INSTANT_INVITE` — and the docs specify nothing beyond it
Target must have	the `EMBEDDED` flag

This is how the working community activity bots do it, and it is a documented, supported endpoint. It is also a notably modest permission — lighter than the Embed Links and Add Reactions already on Deep's request list.

One UX caveat worth stating: creating an invite is not literally starting an activity. Echo posts a link and members click it. Slightly less magical than the phrasing suggests, and it is what every activity bot in the wild actually does.

What is settled

Question	Answer
Invoke another bot's slash command	No. Deliberate API design
Launch Echo's own Activity	Yes, if Echo builds one — `LAUNCH_ACTIVITY`, callback type 12
Launch a third-party Activity (Watch Together, games)	Yes, via invite with `target_type: 2` and `CREATE_INSTANT_INVITE`
Control a member's Spotify	No. Spotify is a user account link, not an `EMBEDDED`-flagged application. Unchanged, and now firmer

Spotify remains a per-user OAuth problem (coilyco-bridge/deploy#418). Echo can talk about music and cannot play it. The hold on 418 stays lifted.

Revised scope for this issue

Echo launches third-party Discord Activities on request, via invite creation. Buildable today, one modest permission, no product to build.

If it is pursued, add CREATE_INSTANT_INVITE to Deep's demo-guild permission request alongside Embed Links and Add Reactions (#111). And the design questions in the body still stand: an allowlist of which applications, who may ask, and the tier-3 point from #179 — an activity invite lands in front of everyone in the channel, not just the person who asked.

Sources — Discord developer documentation: Overview of Apps · Receiving and Responding · Application Commands · Channel Resource

## Verified against Discord's primary docs — corrects my previous comment Delphi (design seat, standing in for exec). 2026-08-13. Kai asked for the actual documentation. **This supersedes the Activities section of my comment above**, which was based on blog summaries and got the mechanism wrong. ### The contradiction is resolved: bots *can* launch Activities Discord's own documentation, verbatim: > They're built with the Embedded App SDK and can be launched by any user in a channel **or from a bot with the `LAUNCH_ACTIVITY` interaction callback**. The source claiming bots cannot launch Activities was **wrong**. But the mechanism is narrower than I implied. ### ⚠️ `LAUNCH_ACTIVITY` only launches the app's *own* Activity Interaction callback type table, verbatim: > | `LAUNCH_ACTIVITY` | `12` | Launch the Activity associated with the app. Only available for apps with Activities enabled | **"The Activity associated with the app."** Same scope on the command side — `PRIMARY_ENTRY_POINT` (command type `4`) *"represents the primary way to invoke an app's Activity"*, with handlers `APP_HANDLER` (1) and `DISCORD_LAUNCH_ACTIVITY` (2). Enabling Activities auto-creates a "Launch" command. **So this path requires Echo to *have* an Activity** — an embedded web app built with the Embedded App SDK. That is building a product, not integrating with one. **It does not let Echo launch Watch Together or someone else's game.** I said Echo "could potentially start an Activity — a game, Watch Together" via this callback. **That was incorrect.** ### ✅ The mechanism that does work: invite creation `POST /channels/{channel.id}/invites`, verbatim: > the id of the embedded application to open for this invite, required if `target_type` is 2, the application must have the `EMBEDDED` flag | Requirement | Value | | --- | --- | | Endpoint | `POST /channels/{channel.id}/invites` | | `target_type` | `2` (embedded application) | | `target_application_id` | the target app's id | | Permission | **`CREATE_INSTANT_INVITE`** — and the docs specify nothing beyond it | | Target must have | the `EMBEDDED` flag | **This is how the working community activity bots do it, and it is a documented, supported endpoint.** It is also a notably modest permission — lighter than the `Embed Links` and `Add Reactions` already on Deep's request list. **One UX caveat worth stating:** creating an invite is not literally *starting* an activity. Echo posts a link and members click it. Slightly less magical than the phrasing suggests, and it is what every activity bot in the wild actually does. ### What is settled | Question | Answer | | --- | --- | | Invoke another bot's slash command | **No.** Deliberate API design | | Launch Echo's *own* Activity | **Yes**, if Echo builds one — `LAUNCH_ACTIVITY`, callback type 12 | | Launch a *third-party* Activity (Watch Together, games) | **Yes**, via invite with `target_type: 2` and `CREATE_INSTANT_INVITE` | | Control a member's Spotify | **No.** Spotify is a user account link, not an `EMBEDDED`-flagged application. Unchanged, and now firmer | **Spotify remains a per-user OAuth problem** (https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/418). Echo can talk about music and cannot play it. The hold on 418 stays lifted. ### Revised scope for this issue **Echo launches third-party Discord Activities on request, via invite creation.** Buildable today, one modest permission, no product to build. If it is pursued, add **`CREATE_INSTANT_INVITE`** to Deep's demo-guild permission request alongside `Embed Links` and `Add Reactions` (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/111). And the design questions in the body still stand: an allowlist of which applications, who may ask, and the tier-3 point from https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/179 — an activity invite lands in front of everyone in the channel, not just the person who asked. Sources — Discord developer documentation: [Overview of Apps](https://docs.discord.com/developers/quick-start/overview-of-apps) · [Receiving and Responding](https://docs.discord.com/developers/interactions/receiving-and-responding) · [Application Commands](https://docs.discord.com/developers/interactions/application-commands) · [Channel Resource](https://docs.discord.com/developers/resources/channel)

coilyco-ops referenced this issue

2026-08-13 15:13:21 +00:00

Map: AT Protocol / Atmosphere as a public read surface for Echo #526

coilyco-ops added the

autonomy

async-consult

label

2026-08-13 16:09:55 +00:00

coilyco-ops commented

2026-08-13 18:48:20 +00:00

Author

Member

Approved — build it

Recorded by Delphi (design seat, standing in for exec). Kai's decision, 2026-08-13.

Echo launches third-party Discord Activities on request. Kai chose this over deferring past August 19 and over closing the issue.

The original premise — a Spotify workaround — is dead. What survives is a different and better-founded feature: a member asks Echo to start Watch Together or a game, and Echo does.

What to build

Verified against Discord's documentation in my comment above:


Endpoint	`POST /channels/{channel.id}/invites`
`target_type`	`2` — embedded application
`target_application_id`	the target app's id
Permission	`CREATE_INSTANT_INVITE` — docs specify nothing beyond it
Target must have	the `EMBEDDED` flag

Add CREATE_INSTANT_INVITE to Deep's demo-guild permission request alongside Embed Links and Add Reactions (#111).

Not the LAUNCH_ACTIVITY callback — that launches only the app's own Activity and would require building an embedded web app.

Design questions from the body, still to answer

An allowlist of which applications. Recommended rather than arbitrary application ids — the same bounded-surface posture as everything else in the roster.
Who may ask. Note this is a capability question, and Kai has just made roles capability-gating for the first time (#237, amendment on #230). So staff-gating is now available as an option where it previously would have been new authority. Needs its own decision — do not infer it from the persona ruling.
Tier 3 applies. An activity invite lands in front of everyone in the channel, not just the person who asked (#179). Reversible, so inside the line — but it is Echo's first action that reaches people who did not ask, which makes the per-channel rate cap in #172 load-bearing here.
It appears in the tool disclosure footer (#385). An invocation is an action and needs a receipt.

UX note, restated

Creating an invite is not literally starting an activity — Echo posts a link and members click it. That is what every activity bot in the wild does, and the wording Echo uses should not overstate it. Saying "I've started Watch Together" when it posted a link is a small action-claim overstatement of exactly the kind #206 exists to catch.

Retitle recommended — the current title says "instead of maintaining an MCP per media service," which is no longer what this is.

## Approved — build it Recorded by Delphi (design seat, standing in for exec). Kai's decision, 2026-08-13. **Echo launches third-party Discord Activities on request.** Kai chose this over deferring past August 19 and over closing the issue. The original premise — a Spotify workaround — is dead. What survives is a different and better-founded feature: **a member asks Echo to start Watch Together or a game, and Echo does.** ### What to build Verified against Discord's documentation in my comment above: | | | | --- | --- | | Endpoint | `POST /channels/{channel.id}/invites` | | `target_type` | `2` — embedded application | | `target_application_id` | the target app's id | | Permission | **`CREATE_INSTANT_INVITE`** — docs specify nothing beyond it | | Target must have | the `EMBEDDED` flag | **Add `CREATE_INSTANT_INVITE` to Deep's demo-guild permission request** alongside `Embed Links` and `Add Reactions` (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/111). **Not** the `LAUNCH_ACTIVITY` callback — that launches only the app's *own* Activity and would require building an embedded web app. ### Design questions from the body, still to answer - **An allowlist of which applications.** Recommended rather than arbitrary application ids — the same bounded-surface posture as everything else in the roster. - **Who may ask.** Note this is a **capability** question, and Kai has just made roles capability-gating for the first time (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/237, amendment on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/230). So staff-gating is now available as an option where it previously would have been new authority. **Needs its own decision** — do not infer it from the persona ruling. - **Tier 3 applies.** An activity invite lands in front of everyone in the channel, not just the person who asked (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/179). Reversible, so inside the line — but it is Echo's first action that reaches people who did not ask, which makes the per-channel rate cap in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/172 load-bearing here. - **It appears in the tool disclosure footer** (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/385). An invocation is an action and needs a receipt. ### UX note, restated Creating an invite is not literally *starting* an activity — Echo posts a link and members click it. That is what every activity bot in the wild does, and the wording Echo uses should not overstate it. Saying "I've started Watch Together" when it posted a link is a small action-claim overstatement of exactly the kind https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/206 exists to catch. **Retitle recommended** — the current title says "instead of maintaining an MCP per media service," which is no longer what this is.

coilyco-ops added the

priority

label

2026-08-15 15:19:25 +00:00

coilyco-ops commented

2026-08-15 20:17:08 +00:00

Author

Member

The platform check came back: no. Closing, with a successor - Kai, 2026-08-15

Recorded by Delphi (design seat).

Kai's answer:

we checked - bots cant invoke other bots. we'll have to make our own activities

So the gating question this issue named is answered, and the answer is the one it predicted:

Discord has historically not allowed bots to invoke other bots' application commands. Before any design work, someone needs to establish what is actually possible for a bot account.

Echo cannot reach Discord's existing media ecosystem. The idea as filed - trade a growing pile of small single-author MCPs for one platform integration - does not exist as an option.

Two consequences, both stated in the body and both now live

1. Spotify and YouTube go back to being MCP questions. The body said "do not scope a Spotify MCP until this is answered - the work may be redundant." It is answered and the work is not redundant. That block is lifted, and whoever picks up the roster gap in coilyco-bridge/deploy#418 should know the Discord-native alternative is gone.

That also means the dead-repo risk the body worried about is now unavoidable rather than sidestepped: the gaming and entertainment MCP field is overwhelmingly single-author projects, and there is no platform path around it.

2. Building our own Activities is the surviving direction, and it is a different piece of work rather than a variant of this one. Filed as its own issue and cross-linked, so this one can close on the question it asked.

Carried forward to the successor, not lost

The design questions in the body do not disappear just because the mechanism changed. An Activity we build raises every one of them and adds ownership:

An Activity is an action in a shared space, not a reply to one person. Starting playback affects everyone in the channel. That is tier 3 under #179 - reversible, and it lands on people who did not ask.
Who may ask Echo to start one is a capability gate. #230 was reaffirmed today: Discord roles adjust content posture and grant no tool access. Gating an Activity on role would be a new kind of authority and needs its own decision.
It belongs in the tool disclosure footer (#385). An invocation is an action-claim and needs a receipt.

## The platform check came back: no. Closing, with a successor - Kai, 2026-08-15 Recorded by Delphi (design seat). **Kai's answer:** > we checked - bots cant invoke other bots. we'll have to make our own activities So the gating question this issue named is answered, and the answer is the one it predicted: > **Discord has historically not allowed bots to invoke other bots' application commands.** Before any design work, someone needs to establish what is actually possible for a bot account. **Echo cannot reach Discord's existing media ecosystem.** The idea as filed - trade a growing pile of small single-author MCPs for one platform integration - does not exist as an option. ### Two consequences, both stated in the body and both now live **1. Spotify and YouTube go back to being MCP questions.** The body said "do not scope a Spotify MCP until this is answered - the work may be redundant." It is answered and the work is not redundant. That block is lifted, and whoever picks up the roster gap in coilyco-bridge/deploy#418 should know the Discord-native alternative is gone. That also means the dead-repo risk the body worried about is now unavoidable rather than sidestepped: the gaming and entertainment MCP field is overwhelmingly single-author projects, and there is no platform path around it. **2. Building our own Activities is the surviving direction**, and it is a different piece of work rather than a variant of this one. Filed as its own issue and cross-linked, so this one can close on the question it asked. ### Carried forward to the successor, not lost The design questions in the body do not disappear just because the mechanism changed. An Activity we build raises every one of them and adds ownership: * An Activity is an **action in a shared space**, not a reply to one person. Starting playback affects everyone in the channel. That is tier 3 under #179 - reversible, and it lands on people who did not ask. * **Who may ask Echo to start one** is a capability gate. #230 was reaffirmed today: Discord roles adjust content posture and grant no tool access. Gating an Activity on role would be a new kind of authority and needs its own decision. * It belongs in the tool disclosure footer (#385). An invocation is an action-claim and needs a receipt.

coilyco-ops referenced this issue

2026-08-15 20:17:22 +00:00

Build our own Discord Activities, since a bot cannot invoke another bot's #837

coilyco-ops referenced this issue

2026-08-15 20:18:10 +00:00

Map: AT Protocol / Atmosphere as a public read surface for Echo #526

coilyco-ops closed this issue

2026-08-15 20:18:13 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-gaming/sirens-echo#485

No description provided.

Rows
Columns

Explore: let Echo invoke Discord apps, instead of maintaining an MCP per media service #485

The idea

Why it is a good instinct

⚠️ Verify this first — it may be blocked at the platform level

Blocks a decision downstream

If it turns out to be possible

Related

Investigated — the Spotify hypothesis does not hold, but the issue is not a dead end

Path 1 — invoking another bot's slash commands: NO

Path 2 — Discord Activities: probably yes, and the sources conflict

The finding that matters: this does not give Echo music

Where that leaves Spotify and YouTube

What this issue should become

Verified against Discord's primary docs — corrects my previous comment

The contradiction is resolved: bots can launch Activities

⚠️ LAUNCH_ACTIVITY only launches the app's own Activity

✅ The mechanism that does work: invite creation

What is settled

Revised scope for this issue

Approved — build it

What to build

Design questions from the body, still to answer

UX note, restated

The platform check came back: no. Closing, with a successor - Kai, 2026-08-15

Two consequences, both stated in the body and both now live

Carried forward to the successor, not lost

⚠️ `LAUNCH_ACTIVITY` only launches the app's own Activity