MCP Server

The DPO2U MCP Server is the production-facing interface that exposes compliance tools to external agents, developer platforms, and internal automation.

Its role is deliberately narrow:

• accept well-scoped requests
• execute compliance logic asynchronously when work is expensive
• return machine-readable status and artifacts
• avoid becoming a warehouse of unnecessary personal data

Why MCP is the integration surface

Model Context Protocol (MCP) gives DPO2U a standard way to expose tools without forcing every integrator to learn the internal stack.

That matters because DPO2U is not trying to win by building a proprietary UI. The differentiator is a toolable compliance surface that other software can call.

Operational status

The public endpoint https://mcp.dpo2u.com responded with HTTP 200 during VPS validation.

During the same validation window, the MCP layer was the most reliable public entry point for capability discovery through:

• https://mcp.dpo2u.com/tools
• https://mcp.dpo2u.com/openapi.json

That makes the MCP layer the most reliable public entry point today.

At the same time, the docs should stay explicit about downstream constraints:

• public chain settlement paths may evolve independently of the MCP surface
• the live public truth for capability discovery is the MCP runtime itself
• when proof-generation or settlement flows are being hardened, the docs should say so explicitly

Architecture role

The key point is the non-blocking design: slow operations should be queued and polled rather than forcing long-lived synchronous requests.

Async, non-blocking posture

For real workloads, compliance operations can involve:

• schema validation
• document generation
• external evidence fetches
• proof generation
• chain submission or local settlement

Those steps are too variable to treat as a single blocking HTTP call in every case. The production-facing contract should therefore prefer:

1. request accepted
2. job ID returned
3. poll or callback for status
4. result retrieval once complete

Recommended response pattern

{
  "job_id": "job_01H...",
  "status": "accepted",
  "status_url": "https://mcp.dpo2u.com/jobs/job_01H...",
  "estimated_next_step": "schema_validation"
}

And later:

{
  "job_id": "job_01H...",
  "status": "completed",
  "result": {
    "company_id": "cnpj:12.345.678/0001-90",
    "score": 87,
    "schema_version": "dpo2u/lgpd/v1",
    "evidence_cid": "bafy..."
  }
}

Privacy posture: no unnecessary PII

The MCP Server should be documented as privacy-minimizing by default.

That means:

• do not require raw personal data when a derived attribute is enough
• prefer hashes, references, CIDs, and scoped metadata over verbose payloads
• keep retention narrow and explicit
• treat on-chain publication as a last step for proofs or references, not a place to dump application data

Public docs stance

DPO2U uses compliance infrastructure, but public docs must not imply that the MCP layer is a general-purpose processor of arbitrary PII. The safer and more accurate statement is that the server is designed to operate on minimal necessary compliance artifacts.

Tool surface

The right way to describe the MCP surface is by capability categories, not by a short marketing list that can drift from runtime.

The public MCP runtime exposes its live inventory through /tools and /openapi.json, and those runtime discovery surfaces should be preferred over any hardcoded count in docs or UI copy.

Representative categories include:

Capability category	Purpose
Health and status	Check service availability and readiness
Compliance generation	Create structured compliance artifacts
Validation and scoring	Evaluate completeness, quality, or conformance
Evidence retrieval	Return machine-readable artifacts and references
Workflow orchestration	Start, inspect, or continue multi-step jobs
Attestation-adjacent operations	Support verification and downstream proof flows

The full, generated list of tools (name, description, required parameters) is in the Tool catalog. At the time of its last generation the live endpoint reported 77 tools (64 static, 13 extended); regenerate it with node scripts/gen-mcp-tools.mjs rather than editing the count by hand.

Runtime beats copy

If you need the exact live inventory, consult the MCP runtime directly instead of relying on a static count embedded in UI or marketing text.

Sync vs async split

Pattern	Use when	Example
Synchronous	Read-only, bounded, fast operations	check_compliance_status
Asynchronous	Generation, proof, chain, or multi-step analysis	generate_lgpd_kit, verify_compliance_proof

Failure semantics

A production-facing MCP service must distinguish clearly between:

• accepted but not finished
• finished with a negative compliance result
• temporarily blocked by infrastructure
• rejected due to invalid input

Example blocked response:

{
  "job_id": "job_01H...",
  "status": "blocked",
  "reason": "public_chain_path_unavailable",
  "recommended_path": "retry_via_local_node"
}

That is more honest and more useful than pretending every request maps to a single success path.

Security and trust boundaries

The MCP layer is an orchestration and integration surface. It is not the source of truth for every statement it returns.

Depending on the tool, truth may come from:

• schema validation rules
• stored artifacts identified by CID
• auditor-agent outputs
• local chain execution results
• verified contract state

The documentation should preserve those boundaries so integrators know which layer they are relying on.

What's next

• Getting Started — first integration steps
• Architecture — current stack and real deployment status
• Schemas — machine-readable payload structure
• Research / Attestation routing — why routing matters as the protocol expands