commercial

Start a real DigitalPublic trial

dp_commercial_start_live_trial

Idempotent

Start an idempotent 14-day trial with up to three active real projects, 2,000 total units, up to five connected tools and supervised write access. Sensitive actions still require human approval. A single passwordless email verifies identity, establishes the portal session and resumes provisioning. Keep the limited statusToken in MCP client state; never paste it into conversation text.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`email`	Yes
`locale`	No		es
`company`	No
`runtime`	Yes
`channels`	No	Enrollment channel ids. Prefer trialChannels returned by dp_commercial_list_integrations. Connector aliases such as meta are accepted for compatibility.
`projectUrl`	No
`projectName`	No
`idempotencyKey`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ok`	Yes
`data`	Yes
`error`	Yes
`links`	Yes
`version`	Yes
`evidence`	Yes
`nextAction`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 4, 2026

addedInput schema / properties / channels / description

Added value: +"Enrollment channel ids. Prefer trialChannels returned by dp_commercial_list_integrations. Connector aliases such as meta are accepted for compatibility."

Changed5 schema fields changedSep 4, 2026

addedInput schema / properties / channels

Added value: +{
+  "default": [],
+  "items": {
+    "maxLength": 64,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 24,
+  "type": "array"
+}

addedInput schema / properties / projectName

Added value: +{
+  "maxLength": 160,
+  "type": "string"
+}

removedInput schema / properties / projectUrl / format
```
Removed value: -"uri"
```
addedInput schema / properties / projectUrl / maxLength
```
Added value: +2000
```

changedInput schema / required

Previous value: -[
-  "email",
-  "projectUrl",
-  "runtime",
-  "idempotencyKey"
-]New value: +[
+  "email",
+  "runtime",
+  "idempotencyKey"
+]

AddedSep 1, 2026

TDQS

A3.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds substantial behavioral context beyond the annotations: supervised write access, human approval for sensitive actions, passwordless email verification, session establishment, provisioning resumption, and the statusToken handling warning. This is genuinely useful operational detail for an agent invoking the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four dense sentences with no filler. The core trial limits are front-loaded, followed by critical security and session behavior. Every sentence adds information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers operational behavior and security well, and an output schema exists for return values. However, with eight parameters and very low schema coverage, the lack of guidance on several input fields and the absence of usage alternatives leave meaningful gaps for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 13%, so the description must compensate for undocumented parameters. It adds meaning for email (identity verification, portal session) and implies idempotencyKey behavior, but runtime, channels, projectUrl, projectName, company, and locale remain unexplained in both the schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: start a 14-day DigitalPublic trial, with concrete limits (three projects, 2,000 units, five tools). It does not explicitly contrast itself with sibling tools such as dp_commercial_start_checkout or dp_commercial_get_live_trial_status, so it falls short of full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use is implied: call this when you need to start a real trial. However, there are no explicit when-to-use, when-not-to-use, or alternative tool references, so the agent must infer selection from the verb and resource rather than being guided toward the correct sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All commercial tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?