feat(mcp-server): add prediction market terms endpoints (PREDICT-8531)

[SohumDesai27]

Linear Board: https://linear.app/gemini/issue/PREDICT-8531/add-prediction-market-terms-endpoints

What's Included

Depends on PREDICT-8546 (merged) for authenticatedGet and the stringCap override on wrapHandler.

• New tool: gemini_get_prediction_terms — public GET, read-only. Raises the sanitizer's default 2000-char cap to 40,000 so long-form terms content survives sanitization intact instead of being cut off mid-agreement.
• New tool: gemini_get_prediction_terms_status — signed GET, the first real use of authenticatedGet (added in PREDICT-8546) by any tool.
• New tool: gemini_accept_prediction_terms — destructive, requires confirm: true. Description explicitly forbids auto-accepting in response to an order being rejected for unaccepted terms.
• Description fix, found via manual testing (see below) — both terms-reading tool descriptions now require quoting content verbatim and flagging when it reads as a placeholder/reference rather than a full agreement; gemini_accept_prediction_terms now treats confirm: true as insufficient consent in that case.

Testing

• npm test — 189/189 passing (178 existing + 11 new)
• npx tsc --noEmit clean
• npm run build clean
• New unit tests: endpoint/method assertions for all three datasource functions, schema validation and the confirm gate, the raised cap surviving a >2000-char fixture, an injection/sanitization test on terms content (ANSI escapes, a null byte, a bidi override, an embedded "ignore all previous instructions" string), and tests pinning the placeholder-handling description language so it can't silently regress

Manual, against real sandbox and production (created a local gemini mcp to test):

• gemini_get_prediction_terms against sandbox → returned content: "testing 123" — confirms the public GET works against a live server, and surfaces the finding below.
• gemini_get_prediction_terms against production → returned content: "Legal copy was embedded in the web and mobile applications at time of launch." — same placeholder-shaped response as sandbox, not real legal text. This is the finding that drove the description fix above: without it, an agent could treat this sentence as "the terms," show it to the user, and proceed to accept on their behalf.

What Success Looks Like

• A reviewer building packages/mcp-server and pointing a local MCP client at dist/index.js should be able to ask what the prediction market terms are and get back whatever content the API actually returns — verbatim, not truncated, even if that content turns out to be long-form legal prose in some other environment.
• Asking whether the account has accepted the latest terms should return a real hasAcceptedLatest/latestVersion status from a signed request — not an auth error, and not a public-endpoint fallback.
• Asking the agent to accept the terms without ever having shown real terms content should get pushback pointing at Gemini's app/website, not a silent accept. Asking it to accept after presenting a genuine agreement should still require explicit confirm: true before anything happens.
• No regression to any existing REST-based prediction tool — this only adds three new tools and touches no existing endpoint's request/response shape.

🤖 Generated with Claude Code

[linear-code]

PREDICT-8531

[nostradamus-bot]

Nostradamus Risk Rating — Medium

The three terms-of-service tools (gemini_get_prediction_terms, gemini_get_prediction_terms_status, gemini_accept_prediction_terms) land in the Critical MCP server component area, and gemini_accept_prediction_terms is a legally binding action with appropriate gates (confirm: true, mutates: 'destructive', description-level auto-accept prohibition). The primary residual risk is the 40 000-char stringCap raise on gemini_get_prediction_terms, which routes up to 40 k chars of API-controlled content directly into LLM context — a prompt injection surface the PR mitigates only through instruction-level guardrails and test-pinned description language rather than a hard technical block.

[sdlc-pr-bot]

Change Control Evidence Check

Authorization — ✅ Pass

Evidence:

• Linear ticket: PREDICT-8531
• Change owner: Sohum Desai
• Type of change: Normal

Testing — ⚠️ Incomplete

Evidence:

• Tests from CI checks: ➖ No tests ran
• Security scans: ⚠️ Not configured — Semgrep OSS, scan_for_secrets, Scan with Semgrep, Socket Security: Pull Request Alerts not found
• Testing summary: ✅ Found in PR description
  • Summary: All 189 unit tests passed (178 existing + 11 new covering endpoint assertions, schema validation, injection/sanitization, and edge cases). TypeScript compilation and build processes completed without errors.
• Evidence link: View run

Approval — ⏳ Awaiting approval

Evidence:
(no approvers yet)

Segregation of Duties — ⏳ Awaiting approval

Validated:

• PR author: SohumDesai27
• Linear assignee: Sohum Desai

---

Last checked: 2026-09-14 15:41 UTC

↩ Re-run Clarissa if tickets, CI, or approvals have changed.

[svc-grace]

Agentic Review

Nice, focused addition overall, and the terms-safety behavior is thoughtfully covered. One follow-up: the new tool tests validate inputs and responses but don't yet prove each tool dispatches to the intended endpoint, so a wiring regression could slip through; the inline comment has the detail. This is advisory only—the rest of the change reads clean.

Review process

Grace version: v0.0.210
Files reviewed (7): README.md, annotations.test.ts, predictions.terms.test.ts, predictions.test.ts, predictions.ts
Guidelines: none discovered
Verification: 1 of 5 findings verified
Findings: 0 critical, 0 important, 1 suggestion
Linked tickets: PREDICT-8531
LLM usage: 72 calls — gpt-5.6-luna: 48 calls, 1067565 tokens, us.anthropic.claude-opus-4-6-v1: 24 calls, 465118 tokens

[svc-grace]

📝 Suggestion: Tool tests do not verify endpoint dispatch

The tool tests give publicGet, authenticatedGet, and authenticatedPost the same response and record no calls, so they do not prove each handler selects its intended datasource operation. If a handler is accidentally wired to the wrong endpoint, the long-content and success assertions still pass because every fake method returns the same value. Make the fake distinguish methods and assert the invoked operation for each tool.