Providers

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

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, etc.).
  • 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 (e.g., for 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" — they're owned by the root scene (the world) 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.

This is the boring-but-important kind of plumbing the framework gets right so providers don't have to.

Cross-provider joins happen at the agent

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

This means: there's no "GitHub-Slack bridge plugin." There's GitHub (a provider), Slack (a provider), and an agent that knows tools from both. Composition happens at the LLM, not at provider definition.

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, so new ones land as people need them.

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 & documents — Daslab's own content types: notes, documents, 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

  • Knowledge Bases — notes with folders and links; providers ship one too.
  • Assets — what providers produce.

Updated 2026-06-30