Skip to main content
Twin ID: discord Discord is a REST-first twin. It is built for the bot workflows developers actually automate: reading guild state, managing channels and messages, running webhook flows, working with threads, managing guild commands, and handling interaction responses after a real invocation.

​
Covered workflows

  • Bot identity and application metadata
  • Guild, role, member, and channel reads
  • Channel create/edit/delete and invite lifecycle
  • Message create/edit/delete, bulk delete, reactions, and pins
  • Webhook create/execute/edit/delete and webhook message lifecycle
  • Thread create/join/leave/member/archive flows
  • Guild command list/create/edit/delete and bulk overwrite
  • Interaction callback and original-response lifecycle after a captured real invocation

​
Fidelity status

  • REST-first contract with live differential validation against real Discord for the approved REST workflow profile
  • Generated 40-60 step workflow differential support in Forge
  • Harvest-backed replay fixtures for the approved audited tranche
  • Real captured interaction fixtures for the interaction response slice

​
Notes

  • Discord does not expose an official service MCP surface for bot operations, so Archal treats this twin as REST-first.
  • The twin follows workflow semantics, not literal fixture text. Custom seeds can rename channels, roles, and messages without getting locked to harvested names.
  • Dedicated weekday scheduled canary runs the approved REST workflow differential against real Discord.
  • The same scheduled canary also runs harvested interaction-response replay plus stale-row regression coverage locally.
  • Route-mode archal/vitest support is now available for Discord. Because Discord is REST-first, tests usually talk to discord.com/api/v10 with fetch, discord.js REST, or another HTTP client instead of an MCP surface.
  • The largest remaining fidelity gap is fresh live inbound interaction delivery and richer component/modal flows.