Tools And Integrations

Use This Doc For

Start With The Object You Are Managing

“Available,” “configured,” and “usable by this coworker now” are different claims. Choose the surface that owns the claim:

Surface What it represents It does not prove
Tool Marketplace / Catalog Known MCP and agent-tool options plus setup and grant guidance That a service is connected or executable
MCP Services Registered service endpoints and the tools they expose That a particular coworker has the required grant
Native Integrations Business-system connections on DPF’s shared credential and governance substrate That every provider operation is supported or write-enabled
Built-in Tools First-party utilities shipped with the platform That a specific workflow has been granted access
Capability Inventory Runtime inventory of internal tools, MCP tools, and AI providers already registered for agents; inventory review counts use canonical discovered entities That catalog setup or a provider account is healthy
Estate Discovery Network collectors and the evidence they produce That a discovered item is already governed in Portfolio

Read Marketplace Readiness

Select the coworker whose readiness you are evaluating before acting on a status:

Catalog sync refreshes known tool metadata. It does not configure credentials, activate a service, grant a coworker access, or prove runtime health.

Connect And Verify

  1. Identify whether the capability should run through an MCP service, a native provider integration, or a built-in tool. Do not create a second connection path for a provider already owned by a native integration.
  2. In the catalog, review category, pricing, applicable archetype, selected coworker, and readiness gaps.
  3. Configure the owning service or integration with the narrowest provider account and permissions that support the intended workflow. Only authorized administrators can enable services and provider connections.
  4. Return to the catalog or capability inventory and verify that registration, setup, and coworker grant state agree.
  5. Exercise a read-only preview or the smallest safe operation. Record which account, object scope, and freshness window the preview represents.
  6. For side-effecting use, verify the coworker’s grant and approval posture, then confirm the resulting proposal and execution evidence under Governance & Audit.

Review Tools A Service Discovers

When you connect an MCP service, the tools it reports start as Waiting for review. Coworkers cannot see or use them yet: a working connection is not permission.

  1. Open Platform > Tools > Services and choose the service.
  2. Expand a tool to read exactly what a coworker would read: its description and inputs, with hidden characters removed.
  3. Choose the permission a coworker needs to use it, and say whether it only reads information or can change things outside the platform.
  4. Select Approve this text, or Block if coworkers should never use it.

If the service later changes an approved tool’s description or inputs, the tool goes back to Waiting for review and is marked Changed since approval. Coworkers keep seeing nothing new until you review it again; the page shows the approved text and the new text side by side. Return to review withdraws an approval immediately. Tools that ship with the platform show Included; their access is set by the release.

Native Integration Previews

Native integration pages use customer-supplied credentials and expose connection state such as connected or error. Their preview cards are read-first operational evidence: for example, a finance integration may show company, customer, invoice, balance, or payment context, while a marketing integration may show account, audience, campaign, traffic, search, listing, or lead context.

Before relying on a preview, confirm:

An integration can be connected while a particular operation remains unsupported. Capability support must be explicit; absence of an error is not proof of support.

Troubleshooting And Recovery

What To Watch

Edit this page on GitHub