TradePause

Pause the impulse. Audit the decision. A self-hosted MCP server that enforces a cooldown and exact confirmation before any paper trade.

Comment

Inspiration

Most trading products compete to remove friction. That is useful for execution, but risky when speed amplifies urgency, concentration, or fear of missing out. TradePause rehearses a pause-and-review workflow using local paper trades.

TradePause was inspired by the gap between knowing a rule and following it under pressure. The goal is not to tell someone what to buy. It is to make an intent inspectable, compare it with disclosed sample limits, and preserve enough local context to review the paper decision later.

What it does

A user states a paper-trade idea in natural language. TradePause then:

  1. turns the sentence into a typed trade intent;
  2. checks position size, concentration, stop loss, daily frequency, and a cooling list against disclosed sample limits;
  3. starts a cooling-off state when a check fails;
  4. rejects order and confirmation attempts while the timer is active;
  5. requires the exact phrase CONFIRM PAPER ORDER after expiry; and
  6. records a local paper fill and generates a retrospective linked to source event IDs.

The browser simulator places the conversation beside a live JSON-RPC trace, so judges can see that one utterance results in real MCP tools/call requests and structured responses. This is an explicitly labeled simulated Alexa+ experience, not a claim of production Alexa+ API integration.

How we built it

We built a Python 3.11+ service with the official MCP Python SDK and FastMCP. It serves stateful Streamable HTTP at /mcp, negotiates MCP revision 2025-11-25, retains sessions, and exposes six tools. FastMCP generates typed input schemas; current output schemas accept arbitrary JSON objects.

The safety behavior lives in a deterministic domain service: a natural-language intent parser, a preflight rule mirror, and a time-based cooldown state machine. SQLite provides a local append-only audit trail plus paper-order state. Mock quotes are deterministic and read-only. A no-build HTML, CSS, and JavaScript client performs the MCP handshake and displays every request and response.

The default demo uses deterministic routing. The optional LLM adapter falls back on errors, but model-selected actions do not establish user consent. Exact paper confirmation is recognized only from the user's original matching text.

Challenges

The hardest challenge was making a pause feel conversational without making the server state vague. The browser orchestrates capture, preflight, and cooldown in sequence. The server requires a bound preflight, applies its approved duration, and checks paper confirmation against the stored cooldown.

We also had to make protocol compliance visible. Sessionful MCP means retaining the server-issued session ID, completing the initialized lifecycle, and attaching the negotiated protocol version to later requests. Finally, we had to show rich tool results without burying judges in JSON strings, so the trace prioritizes structuredContent and pretty-prints a text fallback only when necessary.

Accomplishments that we're proud of

  • Real MCP calls for intent capture, preflight, cooldown, paper confirmation, recent-intent recovery, and review.
  • A fail-closed cooldown that rejects early confirmation and creates no order before expiry.
  • A second confirmation that can only create a local paper fill.
  • An audit review that cites the event records behind its summary.
  • A credential-free default demo with deterministic behavior.
  • A clear safety boundary: no broker integration, no investment advice, and real_money_enabled: false.
  • The 33 automated cases cover domain behavior and selected MCP flows through ASGI. They do not execute the browser JavaScript or establish full protocol conformance.

What we learned

The interface reports remaining time when the user checks the cooldown. Whether this improves decision quality remains to be tested. The implementation work also showed why policy binding and rejected-attempt records belong on the server rather than only in UI sequencing.

We also learned that MCP makes safety boundaries easier to inspect. The available capability is the tool inventory itself: TradePause has tools to structure, check, pause, quote, and review, but no live execution tool. Structured protocol traces made that architectural promise legible in the demo.

What's next

  • Validate the wording and timing with user research focused on decision quality rather than trading performance.
  • Add user-configurable rule profiles with clear provenance and versioned changes.
  • Create richer retrospective views across repeated paper decisions.
  • Add accessibility and multilingual voice-surface testing.
  • Connect the MCP backend to an authorized Alexa+ surface if public integration access becomes available, while preserving the same paper-only boundary.

Tracks

Alexa+ main track only — not entering AWS Builder (no real AWS integration) or the Open Source mini challenge (no qualifying independent open-source contribution during the contest period).

Product Feedback

Alexa+ add-on documentation homepage

  • How we used it: We used the public documentation homepage as the starting point for understanding the Alexa+ add-on track and locating its MCP guidance.
  • What helped: It established the add-on/MCP concept quickly and gave us a useful index into the documentation set.
  • What was difficult: References to select-partner access were not consistent enough across pages to determine the public hackathon route from the homepage alone.
  • Getting started: Initial orientation was quick, but we had to cross-check the FAQ before choosing the browser-client approach.
  • Would we use it again? Yes, as an entry point. We would not use it alone to decide track eligibility or required integration scope.

Alexa+ hackathon FAQ

  • How we used it: We used the FAQ to verify that a real web-based MCP client is acceptable, that no physical Alexa device is required, and that hosting is not required.
  • What helped: It resolved the central implementation-path questions directly and let us keep the demo local and credential-free.
  • What was difficult: These decisive clarifications were separated from the documentation homepage, so discovering the correct route required comparing both sources.
  • Getting started: The answers were clear once found; the friction was finding that the FAQ, rather than the overview page, contained the operative guidance.
  • Would we use it again? Yes. For a hackathon integration, it was the most useful source for translating broad track language into an implementable path.

Official MCP Python SDK (FastMCP, Streamable HTTP, and sessions)

  • How we used it: We built the local MCP server with FastMCP, used stateful Streamable HTTP, negotiated protocol revision 2025-11-25, retained Mcp-Session-Id, and exercised the lifecycle through ASGI tests.
  • What helped: FastMCP made tool registration and typed input-schema generation concise. The SDK handled version negotiation, session creation, transport validation, and structured tool results.
  • What was difficult: We had to distinguish the valid json_response=True response mode from SSE examples and separately verify how session headers and lifecycle messages fit together. The generated output schemas are permissive JSON objects, which also required more careful wording in our submission.
  • Getting started: A basic server was quick to create. Building and testing a stateful browser client took additional protocol reading and explicit handshake tests.
  • Would we use it again? Yes. It removed substantial transport boilerplate, while still leaving enough protocol detail visible to test the boundary honestly.

Devpost submission form

  • How we used it: We used the form structure to organize the track selection, project copy, media, repository details, and required Product Feedback. This repository copy is preparation material and does not by itself prove final online submission status.
  • What helped: The field layout provided a concrete checklist for packaging the project and keeping the Alexa+ main-track claim separate from optional mini challenges.
  • What was difficult: The form does not replace the detailed rules and FAQ, so we still needed a separate evidence checklist to verify language, video, license, feedback, and track-specific requirements.
  • Getting started: The form was familiar to navigate, but a compliant draft required keeping the rules open beside it rather than treating each field as self-explanatory.
  • Would we use it again? Yes. It is effective for submission packaging when paired with a rule-by-rule checklist.

Tools we did not evaluate

We did not receive or use gated Alexa+ partner tools or unreleased Alexa+ APIs. We therefore make no usability claims about them. The demonstrated conversational surface is an explicitly labeled browser client calling the real MCP server.

Links

Built With

Share this project:

Updates

Submission history