MCP, Real Signals, and Documentation
Subtitle: Connect your personal influence model to evidence — without confusing the map for the territory.
Opening provocation¶
A model that only ingests your self-report is a diary with equations. This lecture asks: what external signals (even coarse or synthetic) would falsify a claim your simulation makes — and how do you pull them under MCP policy?
1. What counts as a signal?¶
Owned: logs you control (calendar blocks, draft counts, posting timestamps).
Platform: reach, saves, replies — with known bias and delay.
Synthetic: labeled scenarios when live data is unavailable — document the bridge to reality.
Nothing here requires “big data.” It requires honest scope.
2. MCP in this course¶
Use approved MCP servers to ingest metrics or content your faculty allows. Every connection needs:
Purpose — which variable in your world does this inform?
Scope — read-only vs write; which accounts/endpoints.
Limits — rate, retention, and what you will not automate.
See docs/MCP_MARKETING.md for program guardrails.
3. Documentation that survives challenge¶
Your artifact should carry:
Data card — sources, freshness, known gaps.
Model card — entities, rules, calibration choices.
Decision log — what you changed after seeing signal vs simulation.
Bridge to the notebook¶
07_mcp_signals.ipynb is a template: wire one MCP or export path into a single plot or table, and write one paragraph on what would surprise you if the data disagreed with the model.
Lecture checklist¶
At least one external or synthetic signal tied to a model variable.
MCP scope documented (or explicit statement that only synthetic data was used and why).
One falsifiable claim: “If X were true in data, I would change rule Y.”