Skip to main content

Integration Surfaces

DPO2U has three public-facing integration surfaces. They serve different jobs and should not be conflated:

  1. MCP Server — AI-native tool calling for agents and copilots
  2. SDK / API wrappers — developer-controlled integration inside apps and backends
  3. Frontend — operational visualization for humans

The mistake to avoid is treating these surfaces as interchangeable. They are complementary.

The current truth layer​

The most reliable public integration surface is:

  • https://mcp.dpo2u.com
  • verified from the VPS during this documentation refresh
  • capability inventory discoverable through:
    • https://mcp.dpo2u.com/tools
    • https://mcp.dpo2u.com/openapi.json
Canonical source of capability truth

When the docs mention tool inventory, categories, or public endpoints, the source of truth is the live MCP surface and its OpenAPI description — not hardcoded marketing copy in the frontend.

Which surface should you use?​

If you need to...UseWhy
Let an AI agent call DPO2U directlyMCP ServerStandard tool protocol, machine-readable, agent-native
Embed DPO2U in your own application backendSDK / API wrapperBetter control over auth, retries, typing, and orchestration
Show operators a compliance journey visuallyFrontendBest surface for human review, evidence inspection, and demos
Validate live public capabilitiesMCP + OpenAPIThe runtime surface is the least ambiguous source of truth

Surface-by-surface guidance​

1) MCP Server​

Use MCP when the caller is:

  • an LLM agent
  • a copilot
  • an orchestration system that already understands tool calling
  • an automation flow that benefits from discoverable capabilities

Best for:

  • compliance checks
  • evidence-oriented retrieval
  • bounded generation workflows
  • machine-readable attestation/status queries

Not ideal for:

  • pixel-perfect operator workflows
  • rich human review screens
  • dashboards that need custom UX

2) SDK / API wrapper​

Use the SDK layer when you need:

  • application-side control over auth and sessions
  • domain-specific abstractions around MCP endpoints
  • stronger typing in your own codebase
  • custom orchestration before or after a DPO2U call

The SDK should be treated as a developer facade, not as an independent source of product truth. If a claim in the SDK docs conflicts with the live MCP/OpenAPI surface, the runtime surface wins.

3) Frontend​

Use the frontend when the primary user is human and needs to understand:

  • current compliance posture
  • evidence status
  • attestation progress
  • whether a given screen is showing live, degraded, or demo data

The frontend is not the authoritative source for capability inventory. Its job is to make the system legible, not to redefine what the backend exposes.

The cleanest mental model is:

Decision matrix​

QuestionPreferReason
"What can DPO2U do right now?"MCP / OpenAPIRuntime truth
"How do I wire this into my codebase?"SDKDev ergonomics
"How do I show the workflow to a customer?"FrontendHuman legibility
"How do I verify the claim is real?"MCP / OpenAPI + live endpoint checksAvoids dashboard theater

A note on honesty in demos​

A recurring documentation mistake in infrastructure products is to blur:

  • live telemetry
  • degraded but real data
  • illustrative demo state

DPO2U should keep those modes explicit. The frontend can be compelling without pretending every widget is backed by live production telemetry.

See Frontend Visualization for the display model.