Providers

A provider is an integration plugin. Each connected service in Daslab is implemented as one: GitHub, Gmail, Slack, Postgres, S/4HANA, the file sandbox, an MCP server.

A provider declares: which asset types it offers, which tools operate on them, how to authenticate, how to browse, how to enrich, what shows up in the iOS app, what shows up on the website. It's a single declarative module per provider plus one line in the registry.

A provider declares its types, tools, and auth

A provider definition has these parts (all optional except id, name, auth):

  • Identity: id, name, icon, color, status. The how-it-shows-up basics.
  • Logo and website metadata: declared inline; auto-flows to the integration directory pages.
  • Auth: oauth, api_key, device, custom, or none. Determines the connection flow.
  • Asset types: what kinds of assets this provider produces (an account, a repository, an email, a bucket, and so on).
  • Tools: functions the agent can call. Declared on asset types (operates on instances), on the account asset (needs credentials but not a specific instance), or on the provider itself (rare, truly global).
  • Browse: how to list what the user can pick from when adding assets to a scene.
  • Enrichment: how to fetch fresh data for a cell's rendering.
  • executeTool: given a tool name and input, run it and return the result.
  • buildContext: optional override for how this provider's assets show up in the agent's system prompt.

A working provider is about 30 lines

You declare the account asset type, declare a tool, write the executeTool function, register. The framework handles credential injection, multi-account routing, browse UI, cell rendering, MCP exposure, OTel tracing.

This is the SDK surface. Anyone with a service that has an API can build a provider in an afternoon and have it appear in Daslab as a first-class integration.

Declare the auth type; the framework wires it

Providers declare an auth type. The framework wires up the rest:

  • oauth: standard OAuth 2 / OIDC. The user clicks connect, gets redirected to the provider, comes back with tokens. Multi-account out of the box.
  • api_key: the user enters a key, stored scoped to your workspace; blueprint exports seal credential fields into an encrypted vault instead of carrying them. The defineApiKeyAccount helper collapses ~40 lines of boilerplate.
  • device: device authorization code flow (for example, OpenAI Codex).
  • custom: provider implements its own connection flow (rare).
  • none: provider needs no credentials (rare; a few utility providers).

All credentials live on the account asset. Tools resolve them by walking up the parent chain at execution time. Account asset types are declared with scope: "world", so they're owned by the root scene and shared across every scene in it.

Multiple accounts route automatically

Most providers support multiple accounts per workspace. Connect both your work and personal Gmail; tools can target either. The framework handles the routing: when a tool runs, it inspects the asset's account_id (or an explicit accountId parameter on the tool) and resolves to the right credential set.

Cross-provider joins happen at the agent

A provider is a connection plus its asset types. Cross-provider flows, joining GitHub with Slack or S/4HANA with SuccessFactors, happen at the agent layer. The agent calls tools from multiple providers and joins results in the conversation.

So there's no "GitHub-Slack bridge plugin" to install. There's GitHub, Slack, and an agent that knows tools from both.

100+ providers

The integration directory at /integrations lists them all, from Gmail, GitHub, and Slack to AWS, S/4HANA, SuccessFactors, and research sources like ChEMBL and PubMed. A provider takes an afternoon to build.

Some providers are built in

A few capabilities need no account at all. They're in every scene from the first minute:

  • Sandbox: when no tool fits, the agent writes JavaScript, SQL, or shell and runs it isolated.
  • Web search: the agent can search the web out of the box.
  • HTTP: fetch any URL or call any API directly.
  • Notes and documents: Daslab's own content types, including notes, documents, and uploads.

Everything else connects through an account and shows up in /integrations.

Already have an MCP server? Connect it

If your service speaks MCP, it plugs in as-is: add it as a custom MCP integration and enter the server's remote URL (SSE or streamable HTTP, with auth if the server requires it). Its tools become tools the agent can call, gated by the same approvals as everything else. The directory at /integrations also lists community MCP servers you can connect the same way.

That gets you tools. Wrapping the same API as a native provider (about 30 lines, see above) adds the parts MCP doesn't carry: your service's records show up as assets that render live in a scene, users can pick them from a list when connecting, and your setup docs travel with the integration.

What's next

Updated 2026-08-03