Public launch scope completion

Problem

The MCP server is approaching public launch but several production-safety requirements are unmet. There is no rate limiting on tool calls, no query cost estimation or execution timeout enforcement, and no mechanism to disable individual tools without restarting the server. Rollback procedures are undefined — if a tool schema change breaks downstream agents, there is no versioning strategy or documented revert path. These gaps are acceptable in an internal pilot but would be irresponsible to ship publicly, where unknown agents with unpredictable workloads will interact with the server.

Context

• The backlog for AI agent tool interfaces, execution workflows, and eval-driven behavior tuning is broader than what public launch can safely absorb, so this task has to separate launch-critical scope from attractive but deferrable work.
• A credible launch needs stable default behavior, explicit unsupported cases, and a rollback story for the riskiest surfaces rather than a promise to finish everything.
• Expected touchpoints include dataface/ai/, MCP/tool contracts, cloud chat surfaces, eval runners, and prompt artifacts, launch checklists, and any tasks or docs that currently blur the line between required launch scope and post-launch follow-up.

Possible Solutions

• A - Keep the full backlog in scope until the last minute: preserves ambition, but guarantees launch risk remains unclear.
• B - Recommended: define a minimum externally supportable launch scope and close only those blockers: make explicit deferrals, owner assignments, and rollback expectations.
• C - Shrink scope aggressively to the point of a weak launch: lowers risk, but may undercut the product story and user value.

Plan

1. Audit the open work for AI agent tool interfaces, execution workflows, and eval-driven behavior tuning and classify each item as launch-critical, launch-adjacent, or post-launch follow-up.
2. Document the required launch behaviors, known unsupported cases, and any rollback or kill-switch expectations for high-risk areas.
3. Close or explicitly defer the remaining blockers, linking each deferral to a tracked follow-up with clear risk notes.
4. Reconcile the launch scope with docs, QA/review evidence, and operator expectations so launch readiness is credible and explainable.

Implementation Progress

Review Feedback

• [ ] Review cleared