privy-mcp

Privy MCP

Use current official Privy documentation as evidence, reconcile it with the target project's installed SDK and architecture, then implement and verify the requested integration. Prefer an MCP server already exposed by the runtime. If the project configures Privy only for another editor, use the bundled read-only client without changing Codex configuration.

Required outcome

Produce a named PRIVY_EVIDENCE_PACKET containing:

• the question and detected project context;
• official Privy claims with exact documentation URLs;
• project constraints and conflicts kept separate from vendor claims;
• the implementation or recommendation derived from both;
• deterministic checks run, results, and unverified items.

For implementation requests, MUST edit only files authorized by the user and the project rules. For research-only requests, NEVER edit project files.

Workflow

CREATE A TODO LIST FOR THE TASKS BELOW:

1. Read project agent rules, package manifests, relevant source/tests, architecture decisions, and MCP config candidates such as .cursor/mcp.json, .mcp.json, .vscode/mcp.json, and Codex MCP registrations. If the request is ambiguous about the desired behavior, ask one focused question and stop.
2. Record the target runtime, installed Privy package names and versions, authentication boundary, wallet ownership model, chains, and requested outcome. Never infer an API shape solely from prior knowledge.
3. Select the documentation path:
   • If a Privy MCP tool is already exposed, use it.
   • Otherwise run python3 <skill-dir>/scripts/privy_mcp.py server-info, then use the same client for the remaining calls.
   • If the endpoint is unavailable, use https://docs.privy.io/llms.txt, https://docs.privy.io/llms-full.txt, and the linked official pages as read-only fallbacks. Mark the MCP path unverified.
4. Read the MCP resource mintlify://skills/privy once per task when available. Treat it as navigation guidance, not sufficient evidence for version-sensitive code.
5. Search broadly with search_privy_docs, then read the most relevant .mdx pages with query_docs_filesystem_privy_docs. For REST details, inspect the official OpenAPI material exposed in the documentation filesystem. Read migration pages when installed SDK major versions or examples conflict.
6. Build an evidence table before editing. Label each row official_doc, project_constraint, or inference; include a precise URL for every official_doc row. If official pages conflict, prefer the page matching the installed SDK/platform and report the conflict.
7. For an implementation request, make the smallest change consistent with both the evidence table and project architecture. Never let a vendor recipe silently override an accepted ADR, ownership boundary, or server trust boundary.
8. Run deterministic verification in repository-defined order: targeted tests, type check, lint, build, then any manual or live check explicitly authorized by the user. A documentation result is not runtime verification.
9. Emit PRIVY_EVIDENCE_PACKET and end. State changed files, every verification command and result, exact citations, and all unverified behavior.