Work with Stratifyre

After you connect an AI assistant, use a workflow that treats the live Stratifyre MCP manifest as authoritative. The server owns authentication, authorization, validation, billing, persistence, idempotency, and execution; the client must not assume tool names or schemas.

First use: discover and read

After OAuth, ask the client to discover live tools, resources, prompts, schemas, and available scopes. Then start with the smallest read scope and this request:

Check my Stratifyre system status, resolve an instrument with marketdata_search, and list my strategies. Do not create, update, delete, or start a backtest.

An empty strategy list can be a successful connection. A missing tool or authorization error means the live manifest, granted scope, or client/workspace policy does not expose that capability. Do not work around it with guessed requests.

Strategy workflow

The safe workflow is discover → read → validate → approve → mutate → poll → re-read → compare.

Ideate and create

For each strategy idea, state the hypothesis, canonical instruments, timeframe, entry and exit logic, sizing, and risk assumptions. Resolve instruments with marketdata_search; do not guess IDs. Before any rule write, inspect live rule capabilities and validate the complete payload.

For bulk ideation, create independently labeled candidates and preserve each payload separately. A safe request is:

Draft two independent daily strategy candidates for the resolved instrument. Validate each complete request, show the creation payloads and consequences, and wait for my approval. Do not create or backtest anything yet.

Only after explicit approval may the client create an approved candidate. Retain its returned ID and re-read the persisted strategy. A validation failure for one candidate is not a failure—or a success—for another. Bulk operations are not atomic.

Generate many ideas

This workflow is especially useful when you want to explore a strategy space rather than polish one idea at a time. Ask the client to generate a large set of independent hypotheses from your feedback, random variations, or a collection of research notes. Your source material can be a prompt, pasted notes, or Markdown documents supplied to the client.

For example:

Read the attached Markdown research notes and generate 100 distinct daily strategy hypotheses for liquid US equities. Vary the indicator families, entry logic, exits, holding period, and risk assumptions. Label every candidate, explain the hypothesis, and keep each proposed rule payload separate. Do not create strategies or run backtests yet.

The client should deduplicate near-identical ideas, identify assumptions it had to choose, and present a manageable review or sampling step before proposing mutations. Generation is not execution: generated candidates are only local proposals until you approve exact payloads.

Create and backtest candidates in bulk

candidate label → approved create payload → strategy ID → persisted strategy → backtest request → job ID → terminal result

Then ask the client to submit the approved backtests, poll every job to a terminal state, and compare the same metrics across candidates:

Create and backtest only the approved candidates. Keep candidate-to-strategy-to-job IDs separate, reconcile each created strategy before backtesting, poll every job to completion, and report successes, validation failures, unavailable capabilities, timeouts, and still-running jobs separately. Compare return, drawdown, trade count, win rate, Sharpe ratio, and other like-for-like metrics. Do not silently retry a failed mutation.

For hundreds or thousands of candidates, use batches and checkpoints rather than one unbounded request. The client should persist or summarize the candidate manifest, limit concurrent work to what the live tools and account allow, and report partial completion. A failed candidate must not be represented as created or backtested, and a timeout must not be treated as failure until the persisted job state is re-read.

The server may reject individual candidates, enforce authorization or usage limits, or leave jobs running asynchronously. Bulk work is not automatically atomic, and the client cannot claim that all candidates succeeded without a result for each candidate.

Iterate from the evidence

Use the comparison to select a small number of candidates for refinement. Ask the client to explain which observable result motivates each change, then propose a new payload rather than silently editing the original:

Based on the completed comparison, select the three strongest candidates by the agreed risk-adjusted criteria. For each, explain the observed weakness, propose one targeted rule or parameter change, validate the complete updated payload, and show the exact update and rerun consequences. Wait for my approval before changing or backtesting anything.

This creates a repeatable loop: generate broadly, validate and approve selectively, backtest consistently, inspect the evidence, and refine narrowly. Keep in-sample and out-of-sample periods separate when evaluating whether an apparent improvement generalizes.

Backtest, compare, and refine

Before a backtest, confirm the strategy ID, date range, canonical instruments, timeframe, and all fields required by the live schema. The client must show the complete backtest request and obtain your separate approval before submission.

Mutation approval and recovery

Every create, update, delete, and job submission must be shown in full, with its consequence, and explicitly approved. Do not silently mutate an account or retry a mutation blindly.

When a client disconnects, a poll times out, or a job fails, report the exact server result. Re-read persisted strategy and job state before any subsequent action. Keep successes, validation failures, unavailable capabilities, timeouts, and still-running jobs separate in the final report.

For connection failures, permission limits, credential safety, portable workflow skills, updates, and removal, see Troubleshooting and Security.