MCP

DigitalPublic for MCP-compatible clients and agents

Two remote Streamable HTTP servers separated by purpose and risk.

02

DigitalPublic

  • URL: https://platform.digitalpublic.com/api/mcp
  • OAuth 2.1 Authorization Code with PKCE S256 is recommended. The client discovers authorization from protected-resource metadata and preserves resource, callback, and state.
  • Compatible clients identify themselves through CIMD or Dynamic Client Registration (DCR); access tokens last one hour, refresh tokens rotate, and both can be revoked.
  • read queries data, write prepares mutations, and approve decides on already prepared proposals.
  • Only an authorized person may approve; dpk_ and dpa_ never can.
  • The 14-day trial allows read and supervised write access. Sensitive actions retain human approval.
03

Approval inside the client

  • Interactive MCP App when the host supports it.
  • A tool marked as human interaction and always kept in ask mode for Claude Code.
  • elicitation/create when that capability is negotiated in a Streamable HTTP session.
  • A portal link only as safe degradation for incompatible clients.
04

Advanced alternative: connect with a token

Use this alternative only when the client cannot complete OAuth. Variant A is for MCP clients that accept headers on a remote entry; variant B uses the mcp-remote bridge. Keep the token in the connector secure storage or an environment variable and never paste it into a conversation.

a-remote-url.json
{
  "mcpServers": {
    "digitalpublic": {
      "url": "https://platform.digitalpublic.com/api/mcp",
      "headers": {
        "Authorization": "Bearer dpk_YOUR_PROJECT_API_KEY"
      }
    }
  }
}
b-mcp-remote.json
{
  "mcpServers": {
    "digitalpublic": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://platform.digitalpublic.com/api/mcp?projectId=YOUR_PROJECT_ID",
        "--header",
        "Authorization:${DP_AUTH_HEADER}"
      ],
      "env": {
        "DP_AUTH_HEADER": "Bearer dpa_YOUR_AGENT_TOKEN"
      }
    }
  }
}
05

Diagnosis with the token alternative

The account owner or an administrator creates a dpk_ at https://platform.digitalpublic.com/account when OAuth is unavailable. Multi-project dpa_ tokens are reserved for Partner and legacy scenarios. The same Bearer header works on the REST API: call POST https://platform.digitalpublic.com/api/agent/discover first to receive the project, granted permissions, available modules, and endpoint catalog. With an existing dpa_ token, GET https://platform.digitalpublic.com/api/agent/projects lists every project you can address.

discover.sh
curl -X POST https://platform.digitalpublic.com/api/agent/discover \
  -H "Authorization: Bearer dpk_YOUR_PROJECT_API_KEY"

curl https://platform.digitalpublic.com/api/agent/projects \
  -H "Authorization: Bearer dpa_YOUR_AGENT_TOKEN"
06

Only two MCP servers

The commercial MCP discovers the offer without customer data. The operational MCP works with authorized projects and includes dp_navigator_* tools to assist the external agent. The web assistant uses the same Navigator service internally.

07

Limits

OAuth does not expand the subscription. Visible tools are filtered by plan, modules, status, project, and permission. Approval requires the current version and hash, is claimed atomically, and executes once. Batches are disabled when the provider cannot guarantee true atomicity.

Machine-readable evidence

The same facts are available through API and MCP.

OpenAPI