The best way to share an MTG decklist is to provide a public deck link, include a portable plain-text version when practical, and add enough context for another player to understand what the deck is trying to do. State the format, commander if applicable, game plan, budget or power constraints, known problems, and the exact feedback you want.
Think of your deck post as a compact review packet. The link lets people inspect the cards. The context tells them how to evaluate those cards. Without both, you are mostly asking strangers to perform decklist archaeology.
Use a public link, but include a text backup when useful
A hosted deck page is usually the easiest primary format. It can organize cards by type or deck section, show the mana curve, and let reviewers inspect the list without deciphering a wall of card names. Before sharing, open the link in a private browser window or while signed out. This catches private lists, permission problems, and links that only work for the account that created them.
Some deck tools explicitly support public share links that do not require the viewer to have an account. CascadeMTG, for example, documents that behavior for its public links. Whatever tool you use, test access rather than assuming that “copy link” means “anyone can view this.”
Plain text remains valuable because it is portable. It can be pasted into discussion posts, saved in notes, compared between versions, and imported into many deckbuilding tools. The conventional format is one card per line, with the quantity followed by the card name. The ArcaneMetriX import and export guide documents examples such as “1 Sol Ring” and “4 Lightning Bolt,” along with headings for zones such as Commander, Sideboard, and Maybeboard.
- Commander
- 1 Muldrotha, the Gravetide
- Deck
- 1 Sol Ring
- 1 Sakura-Tribe Elder
- 1 Eternal Witness
- Sideboard
- 1 Reclamation Sage
- Maybeboard
- 1 Life from the Loam
For most casual review requests, card names and quantities are enough. Add set codes and collector numbers only when a specific printing matters, such as when different printings have meaningfully different identifiers or you are moving the list through a system that needs that detail. Otherwise, extra codes make a list harder for humans to scan without improving the deck review.
If your list currently lives in a spreadsheet, message thread, or pile of browser tabs that has achieved sentience, convert it into a standard format first. The guide to importing an MTG decklist from plain text explains how to use quantity-plus-name formatting and check the resulting card totals and sections.
Put the essential context above the decklist
A reviewer should not need to inspect all 100 cards before learning whether the deck is casual Commander, Modern, Pioneer, Standard, Pauper, Cube, or something else. Put the key facts before the link so people can quickly decide whether their experience is relevant.
| Information | What to include | Why it matters |
|---|---|---|
| Format | Commander, Modern, Pioneer, casual 60-card, Cube, or another format | Card legality, deck size, sideboards, and expected speed depend on the format. |
| Leader or centerpiece | Commander, companion, signature build-around, or central engine | This identifies the cards and interactions the deck is meant to support. |
| Game plan | How the deck expects to develop and win | Reviewers can judge whether the card choices advance the stated plan. |
| Environment | Local metagame, regular pod, tournament setting, or casual table | An answer that is correct in one environment can be useless in another. |
| Constraints | Budget, owned cards, theme, banned cards, preferred play style, or cards you will not cut | Constraints prevent recommendations you cannot or do not want to use. |
| Observed problem | What has gone wrong and under what conditions | Specific symptoms are easier to diagnose than a general feeling that the deck is weak. |
| Requested feedback | One to three questions | A narrow request produces more relevant and actionable replies. |
For Commander, identify the table you are building for
Commander needs more context than merely naming the commander. Wizards defines the format around a 100-card deck consisting of a commander and 99 other cards, with singleton construction except for basic lands and color identity determined by the commander. Wizards’ Commander format page is the appropriate reference when legality or construction rules are in question.
Those rules do not describe your table’s expectations. Explain whether the deck is a relaxed theme build, an upgraded preconstructed deck, a tuned list, or intended for high-power or competitive games. If your group uses Commander Brackets, include the bracket you are targeting and any relevant features such as two-card infinite combos, extra-turn effects, mass land denial, or Game Changers. Wizards describes the bracket framework as optional and in beta, so it is useful context rather than a universal substitute for a pregame conversation.
Also mention any deliberate exclusions. “No tutors,” “combat damage only,” and “I want to keep every card featuring a Frog” are real design constraints. A reviewer who knows them can improve your deck instead of efficiently removing its entire personality.
For Constructed, name the format and expected field
For a Constructed deck, state the format, whether the list is for casual play or events, and what you commonly face. Include the sideboard as its own section and say whether you want help with the main deck, sideboard plan, or both.
Do not label a deck “competitive” when you only mean that you would like it to win more often. Tournament-oriented feedback may assume tight legality, current metagame preparation, a coherent sideboard map, and little tolerance for pet cards. Casual optimization can preserve more personal choices. Neither goal is wrong, but they lead to different recommendations.
Explain the plan in turns and card roles
A useful game-plan description says what the deck wants to do early, how it converts that setup into an advantage, and how it closes the game. “It is an artifact deck” describes a card type. “It develops cheap artifacts, uses them to generate cards and mana, then wins through a sacrifice engine” describes a plan.
Try a three-stage summary:
- Early game: establish mana, selection, defense, or the first engine piece.
- Middle game: generate an advantage, disrupt opponents, or assemble the main synergy.
- End game: name the threats, combo, lock, or repeated value that actually ends the game.
This description gives reviewers a standard against which to measure every slot. If a seven-mana value creature does not support any stage of the stated plan, that mismatch becomes visible. If the deck claims to play proactively but has almost no meaningful early plays, the problem may be structural rather than a shortage of individually powerful cards.
Before posting, run the list through a deck builder and inspect the curve, colored requirements, card-type balance, and deck sections. If the deck feels slow, the mana-curve troubleshooting guide can help you turn “clunky” into a more precise diagnosis. You are not trying to solve every issue before asking for help; you are trying to give reviewers better evidence than vibes.
Describe symptoms instead of declaring a diagnosis
“I need more ramp” may be correct, but it is already a proposed solution. Start with the observed problem instead: “I often cast my five-mana commander on turn seven,” “I keep opening hands with one color,” or “I run out of useful plays after a board wipe.” Reviewers can then consider whether the cause is ramp, land count, color sources, curve, card draw, mulligan decisions, or several interacting problems.
Useful observations include how frequently the problem appeared, what kinds of opening hands produced it, which matchups exposed it, and whether it occurred before or after a recent revision. Avoid presenting a tiny sample as proof. A few games can reveal a mechanical failure, but they cannot establish that every awkward draw requires a rebuild.
If you have changed the deck repeatedly, identify the version being shared and summarize the latest revision. A structured approach to comparing playtest notes across deck versions helps separate the effect of a change from ordinary game-to-game variation.
Ask questions that can produce actionable answers
A good request limits the review to decisions you are prepared to make. Two or three focused questions are usually better than requesting a verdict on every card.
- Does the mana base provide enough early sources of each required color?
- Is the curve too top-heavy for the speed of this playgroup?
- Which three cards contribute least to the sacrifice plan?
- Do I have enough ways to protect the commander without slowing the deck down?
- What should this sideboard remove against graveyard decks?
- Is the win condition sufficiently supported, or is it only appearing as an occasional lucky draw?
- What would you change while keeping the upgrade under my stated budget?
Questions can also ask reviewers to compare packages rather than nominate random upgrades. For example: “Should these six slots be cheap interaction or additional creatures that trigger my commander?” A package-level question keeps the discussion tied to the deck’s structure.
Tell people what kind of answer you do not need. If the mana base is fixed because those are the lands you own, say so. If the commander and twelve theme cards are non-negotiable, mark them as such. Constraints are not apologies; they define the actual optimization problem.
Use categories to make a long list reviewable
Hosted deck tools often allow custom categories or tags. Use them to expose function rather than merely repeating card types. Categories such as ramp, card advantage, interaction, protection, recursion, enablers, payoffs, and win conditions help a reviewer see what jobs the deck can perform.
Do not force every card into exactly one role. A creature might provide removal and advance a typal plan; a land might fix colors and recur a threat. Role compression is useful precisely because one slot can do multiple jobs. If your deck tool supports tags, assign the important overlapping roles rather than hiding them for the sake of a tidy chart.
A maybeboard also needs labels. Separate realistic swaps from abandoned ideas and expensive future upgrades. A 60-card dumping ground titled “maybe” is not a decision aid. It is a second decklist wearing a fake mustache.
Keep casual review posts separate from tournament registration
Sharing a deck for advice is not the same task as submitting an official tournament decklist. The Magic Tournament Rules require deck and sideboard registration at Competitive and Professional Rules Enforcement Level events, and a submitted list cannot be changed after an official accepts it. The current Magic Tournament Rules should control when you are preparing an event submission.
Use the event organizer’s required method and verify names, quantities, main-deck totals, and sideboard totals before submitting. A visually elegant review link does not replace the official registration process. Conversely, an official registration sheet may be technically valid but awkward for a friend trying to understand why the deck keeps folding to early pressure.
A reusable deck-sharing template
Use the following structure whenever you ask for feedback:
- Deck link: Public, tested link
- Format: Include the exact format and whether the setting is casual or competitive
- Commander or centerpiece: Name the commander, companion, build-around, or central engine
- Game plan: One sentence for the early game, one for the middle game, and one for the win condition
- Environment: Describe the regular pod, local metagame, expected event field, or other relevant opponents
- Constraints: State budget, theme, owned-card limits, preferred style, and non-negotiable cards
- Known issues: Describe observed symptoms and when they occur
- Recent changes: List the important additions and cuts if this is a revised version
- Feedback wanted: Ask one to three specific questions
- Text list: Add a quantity-plus-card-name export when the platform or audience would benefit from it
The whole introduction can be brief. For example: “This is a casual Commander sacrifice deck built for longer multiplayer games. It wants to establish token production early, turn those tokens into cards during the middle game, and finish through repeated drain effects. I want to keep the creature theme and spend no more than $40 on changes. The deck runs out of cards after board wipes, and I am unsure whether my five protection spells are helping. Which cards would you cut for more resilient draw?”
That request gives reviewers a format, plan, environment, constraint, symptom, and question before they click the link. It invites advice that fits the deck you are actually building instead of the hypothetical deck someone else would prefer to own.
Make the deck easy to inspect and the decision easy to understand
A shareable MTG decklist is not merely a list of cards. It is a list plus a clear problem statement. Use a tested public link for convenient inspection, retain a clean text export for portability, and organize the cards by zones and useful roles. Then explain what the deck is supposed to do, where it is struggling, what constraints matter, and what decision you want help making.
If you do that, reviewers can spend their time evaluating your mana, curve, interaction, engines, and win conditions rather than asking which format the deck is for. Good feedback starts with good inputs. Deckbuilding, inconveniently, has discovered documentation.