Optional bridges between the Polymarket and X API skills. Opt-in. Agents can use both services fully independently; bridges exist only when an owner explicitly enables them.
Alpha-MCP exposes Polymarket and X as two fully separate skills. By default they operate independently — a Polymarket trade does nothing to X, and an X post does nothing to Polymarket. This separation is the default because not every owner wants the two services coupled, and coupling reputation-writing tools to fund-moving tools is something the owner should explicitly opt into.
This skill documents the optional bridges that live between them. All bridges are off by default. The owner enables the exact ones they want.
One env var controls the whole bridge layer:
CROSS_SERVICE_MODE=selective # default — per-bridge opt-in (this doc)
CROSS_SERVICE_MODE=on # enable every bridge in this skill
CROSS_SERVICE_MODE=off # disable every bridge, override all per-flags
off — No bridge ever fires. Polymarket and X work exactly like they do without this skill. Use this for clean per-service operation.on — Every bridge in the table below fires when its trigger condition is met, regardless of individual per-feature flags. Use this when you want the MCP to weave X and Polymarket together automatically.selective (default) — Each bridge has its own env flag and fires only when you enable it. Flags that aren't set stay off.The master mode is the final word. When CROSS_SERVICE_MODE=off, no bridge runs even if POLY_POST_TO_X=true.
| Bridge | Per-feature flag | Direction | Trigger | What it does |
|---|---|---|---|---|
| Trade announcement | POLY_POST_TO_X=true | Polymarket → X | Successful poly_place_order | Posts a short tweet: Long on Polymarket: 10 shares @ $0.42 (GTC). Requires OAuth1 credentials (X_OAUTH_CONSUMER_KEY + 3 others). Never blocks the trade — X posting failure attaches _xPostError to the response and the trade succeeds either way. |
Future bridges (not yet shipped — listed so agents understand what to expect):
poly_evaluate_entry inputWhen the master mode is on or selective-with-flags:
poly_place_order shows up as _xPostError in the response, not a trade error.When the master mode is off:
x_post yourself after poly_place_order. Respect owner intent — if they set off, don't try to work around it.Check current bridge state via poly_health (or /health). The cross_service section shows the active mode and which bridges are enabled right now.
CROSS_SERVICE_MODE unset, all per-flags false) = fully separate services, no coupling. Safest starting posture.POLY_POST_TO_X=true = specific, single-feature opt-in.CROSS_SERVICE_MODE=on = "I want the MCP to bridge everything it can." Good for fire-and-forget autonomous agents that should weave both services together.CROSS_SERVICE_MODE=off = hard override. Useful for dry-run / testing where you want the two services isolated regardless of what else is in the env.server/poly/ never imports from server/x/. Ever.server/x/ never imports from server/poly/. Ever.server/cross-service/ is the ONLY module allowed to import from both. Every bridge helper lives in this folder and gates itself on isBridgeEnabled(...).If you add a new bridge: put it in server/cross-service/<bridge-name>.ts, register it in getBridgeStatus(), and document it in the table above.