Quantitative Trading Research in Codex With MCP

Use Codex to inspect the data contract, retrieve dated dilution events through MCP, and generate a reviewable 20-day event-study script.

Quantitative trading research in Codex works best when the model writes code around documented observations rather than inventing the market inputs. Connect the hosted Alphanume MCP server, inspect the dilution tool schema, retrieve a bounded event cohort, and make Codex save the exact arguments before generating Python. The result should be a reproducible event-study scaffold with explicit timing assumptions, not a claim that dilution events are automatically profitable trades.

The MCP setup guide gives the current two-command OAuth path for Codex and lists all 25 tools. The same account tier described on pricing applies to MCP and REST. For this workflow, the relevant source is the Dilution dataset, a point-in-time record of S-1 registrations with filing timestamps, lifecycle fields, market cap at filing, offered shares, and EDGAR evidence.

Connect Codex and inspect before generating code

Register https://mcp.alphanume.com/mcp with codex mcp add, run codex mcp login alphanume, and confirm the connection with codex mcp list. OAuth resolves the API key and tier attached to the signed-in Alphanume account. Do not paste a key into a prompt or repository. Ask Codex to list the dilution tool's arguments and return fields before it proposes an event definition.

codex mcp add alphanume --url https://mcp.alphanume.com/mcp
codex mcp login alphanume
codex mcp list

The MCP tool is get_dilution_filings. It filters by ticker and filing-date ranges rather than an exact date parameter. Its event time is the filing timestamp, and market cap at filing is measured from the prior trading day. Lifecycle fields can later show effectiveness or withdrawal. Those later fields must not be used as if they were known when the registration first appeared.

Define the event cohort in plain language

A 20-day return calculation needs more than a list of filings. Define which registrations qualify, which timestamp becomes day zero, how after-close filings map to trading sessions, how duplicate amendments are handled, what price source supplies adjusted closes, and whether delisted names remain in the outcome sample. Alphanume supplies the event record. It does not supply a complete price-return backtest in this tool.

Review the dilution field reference and the existing S-1 tracking guide before selecting filters. The post explains access and retrieval, while this workflow adds the Codex handoff from events to a separately sourced return series.

Give Codex a constrained generation prompt

Ask for retrieval first and code second. The prompt should make Codex expose assumptions as constants and stop when the price source or a required field is unavailable. This prevents generated code from quietly substituting an unrelated current quote endpoint or dropping unresolved events.

Use Alphanume MCP to call get_dilution_filings for 2025-01-01 through 2025-03-31.
Keep ticker, filing_timestamp, is_dilutive, is_resale, shares_offered, market_cap_at_filing, accession_number, and filing_url.
Save the exact tool arguments and raw response before transformations.
Then generate Python functions that map each filing to the first eligible trading session and calculate adjusted-close return through session 20 using a separately supplied prices DataFrame.
Do not fetch an undocumented price source. Do not use effective_date or withdrawal_date as filing-time inputs. Preserve events with missing outcomes and print exclusion counts.

The generated code should accept events and prices as inputs, return an audit table, and print counts at each stage. Ask for tests covering an after-close filing, a ticker with no twentieth session, duplicate accession numbers, and a delisted name. Codex can generate these fixtures without claiming they are real observations.

Review the failure modes before trusting output

The largest risk is temporal leakage from lifecycle enrichment. An old event row may now contain the date it later became effective. That field is useful for measuring the registration process but was unknown at initial filing. Separate filing-time features from later outcomes. A second risk is sample selection: a current price vendor may omit securities that failed, changed ticker, or stopped trading before day 20. Those are outcomes, not rows to erase.

• A 403 date-range restriction reflects the account tier and should not be converted into an empty cohort.
• MCP responses have row bounds. Narrow the range or verify truncation before measuring event counts.
• Filing timestamps and trading sessions use different clocks. State the timezone and next-session rule.
• A negative average return alone does not include borrow availability, spreads, halts, or executable short prices.

Reproduce one quarter and save the evidence

Run the bounded quarter, export the raw event response, generated study code, test output, final event-level table, and exclusion summary. Manually open several retained EDGAR links and verify the classification and timestamp. Then rerun the script without Codex and confirm identical event keys and returns. Only after that acceptance test should the date range expand or the code move into a scheduled research job.