1. Ask Muse to create the NexusTrade custom connector
Open a Muse personal-agent conversation and send the connection request below. Meta documents creating a Custom Connector by asking Muse in chat. Follow its authentication handoff and sign in to the intended NexusTrade account; review access before consent. Use the secure credential flow if requested, and keep passwords and tokens out of chat.
Discover the actual NexusTrade tools after authentication. Keep approval for portfolio changes and paid tests in Muse Settings; manage or disconnect the connection under Settings → Connectors. After Muse creates the connector, run the account read below before asking it to work with your portfolio.
Create a Custom Connector named NexusTrade using the Streamable HTTP MCP URL https://nexustrade.io/api/mcp. Use server OAuth discovery and guide me through sign-in. List the tools after authentication. Start with read-only owned portfolio access; do not run research jobs, backtests, edit portfolios, deploy or place orders.2. Check the account with an owned portfolio read
Ask the agent to call fetch_portfolios with the arguments below. Compare the returned portfolio names, IDs and types with your NexusTrade account. fetch_portfolios returns portfolioId; pass that exact value as portfolio_id to get_portfolio. Inspect the structured portfolio.portfolioId, portfolio.type, portfolio.isActive, portfolio.strategies, portfolio.initialValue and portfolio.deployment. For a new account, an authenticated empty list is a valid result. Public stock commentary does not establish account access.
This request excludes live books and positions, includes chat drafts and inactive paper books, and returns up to 50 records per page. Follow subsequent pages before concluding a named book is absent. If OAuth expired, reconnect and repeat this read. For a missing tool, inspect the included app, environment and action permissions. An account mismatch must be fixed before a write.
{
"include_live": false,
"include_paper": true,
"include_chat_portfolios": true,
"include_inactive": true,
"include_positions": false,
"limit": 50,
"page": 1
}3. Freeze one SPY candidate
Proposed mechanics example: one long-only SPY stock strategy pair, $10,000 starting simulated capital and a 50-trading-day simple moving average. The historical example uses interval Day. Enter only while flat when price is above that average; buy 20% of portfolio value. Exit the entire SPY holding when price is at or below the same average. Keep the remainder in cash; use no leverage, options or parameter search.
Have the agent show the complete condition and action objects, then call build_portfolio with that full JSON to validate and canonicalize without saving. Review valid, issues and the returned portfolio. Correct each reported issue before approving create_portfolio with the same accepted JSON. The flat-position guard prevents another purchase on every evaluation while the condition stays true. Record how the configuration handles missing prices, warmup and evaluation timing. These are proposed inputs, not a recommended allocation or a tested trading edge.
Draft exactly one new chat portfolio named "Meta Muse SPY SMA50 review" with initialValue 10000. Use daily SPY prices and a SimpleMovingAverage window of 50 Day bars. Entry: price > SMA50 AND held PositionValue = 0; buy 20% of portfolio value. Exit: price <= SMA50 AND held PositionValue > 0; sell 100% of that holding. No options, leverage or repeated purchases while held. Show the full condition/action configuration and the dividend policy. Call build_portfolio with the full JSON; inspect valid, issues and the canonicalized portfolio without saving. After I approve saving, call create_portfolio with the same accepted JSON, preserve portfolios[0].portfolioId and read that exact ID with get_portfolio. Do not backtest or deploy yet.Create and monitor a separate paper deployment
Deploying an existing live portfolio ID can reactivate real brokerage trading. For this workflow use the newly authored chat candidate and verify the returned deployment is paper. The SDK also separates saved draft IDs from deployment.portfolioId.
| Preview the candidate | build_portfolio | Review the canonical configuration and fix validation issues before saving |
| Author the candidate | create_portfolio | A newly authored chat portfolio, not an existing live account |
| Inspect the target | get_portfolio | Read the exact returned ID and strategies before activation |
| Deploy the chat book | update_portfolio | operations: [{type: "deploy", portfolioId: returnedChatId}] creates paper |
| Find the running book | fetch_portfolios | Keep the resulting deployment ID separately from the original chat/draft ID |
| Read actual paper history | query_portfolio_history | The deployed portfolio curve; never substitute a backtest curve |
No matching rows. Clear the filter to see all records.
4. Approve one paper-copy operation
Read the newly created chat portfolio again and confirm its type, $10,000 simulated capital and complete strategy pair. Keep the saved draft ID and any historical backtest ID in separate fields. After you approve activation, call update_portfolio with only the chat ID below. Deploying that chat candidate creates a paper book; targeting an existing live portfolio can reactivate real brokerage trading.
Record the returned deployment result, then use fetch_portfolios with include_paper=true, include_live=false and include_chat_portfolios=false to find the deployed book. Read its exact ID with get_portfolio and verify paper type, copied strategies and state. Keep the running paper ID separately from the original chat ID. Inspect its evaluation state after the copy, even if the approval succeeded.
{
"operations": [
{
"type": "deploy",
"portfolioId": "<RETURNED_CHAT_PORTFOLIO_ID>"
}
]
}5. Confirm evaluation and the first paper record
Open /portfolio/<RETURNED_PAPER_PORTFOLIO_ID> in NexusTrade. Review the Deployment Center and trading policy on that paper book. Automated Trading is an owner-controlled UI choice; MCP cannot switch it on. If it is off and you choose to begin evaluation, enable it for this verified paper target and select Save Changes. Read back the same portfolio and its policy before reporting it running.
Keep SPY, the 50-day rule, 20% entry allocation and $10,000 initial value fixed during observation. Read the actual deployment frequency: the Day historical interval and a Day indicator window do not set paper cadence. Constant and OpenClose are different evaluation schedules; OpenClose evaluates at both open and close. Record that frequency, when evaluation began and what data was available. Paper behavior is simulated forward execution. A historical curve remains a separate artifact.
6. Monitor the deployed curve, not a replay
Use query_portfolio_history with the exact paper ID below and actual observation dates when applying filters. The expected result identifies the deployed portfolio and paper kind and returns {time, value} points. Follow pagination; an empty first result can mean no history yet. Check evaluation state, market timing and the same ID before diagnosing failure.
Keep a journal of signal, simulated order, holding, cash and history timestamps from the available portfolio and event tools. If the rule does not trade, report that observation. Do not invent a fill or launch a backtest to make the paper curve appear.
{
"portfolio_id": "<RETURNED_PAPER_PORTFOLIO_ID>",
"page": 1,
"page_size": 500
}7. Ask Muse for the next SPY observation
Run the first observation as a single read-only task in Muse. Ask for the verified SPY paper ID, its type and latest history timestamp, then compare the configured 50-day rule with the saved candidate. Keep Muse's connector approval rules on for writes. A conversational reminder should not be treated as proof that a server-side recurring observation was saved.
For each follow-up, reuse the same paper ID and request the new history interval. If authentication expired, reconnect the custom connector and repeat the owned read before resuming. Review the actual tool output; the agent's summary alone cannot verify an activation or simulated fill.
Read my verified SPY paper portfolio <RETURNED_PAPER_PORTFOLIO_ID> using the NexusTrade connector. Show paper type, copied strategy names, evaluation state and latest query_portfolio_history timestamp/value. Compare with my previous observation and report new simulated activity only when the tools establish it. Do not activate another copy, change rules, run a backtest or place broker orders.Recover or stop without a duplicate activation
If the deploy response is missing, read the original draft, list paper books including inactive ones and compare the copied strategy set and creation record. Reuse the existing paper ID when found. An ambiguous timeout is not permission to issue another deploy operation; reconcile the task and account first.
To stop strategy evaluation, turn Automated Trading off in that paper book’s Deployment Center and select Save Changes. Read the same ID and policy to verify the stop. update_portfolio also exposes undeploy for the verified deployed ID when you explicitly choose to stop that deployment. Review existing simulated orders and holdings separately; stopping evaluation does not mean liquidation.
Stopping the external agent or canceling its observation schedule is separate from stopping the NexusTrade book. Save the final paper ID and its observed state before ending the assignment.
Stop this paper deployment and verify its state
After approving a stop, send this update_portfolio request only for the verified running paper ID. Read get_portfolio again and check portfolio.type is paper and portfolio.isActive is false. Retain the ID and history; undeploy is different from delete. Confirm the trading policy separately if you changed Automated Trading in the UI.
{
"operations": [
{
"type": "undeploy",
"portfolioId": "<RETURNED_PAPER_PORTFOLIO_ID>"
}
]
}