Understand how Apps, auth configs, connectors, tools, and MCP relate to each other.
Connector has only a few layers. Once you understand how they relate, every operation that follows becomes intuitive.
Data flows like this:
An App is a type of system you can connect to — each card on the Apps page of the console. It represents a class of external system, such as DingTalk Docs, Yuque, or MySQL, rather than one specific connection.
Apps fall into two categories depending on whether an auth config is required before you connect, and that determines the steps you take:
For the full list, see the App catalog.
An auth config is a definition of an authentication method together with its credentials. More precisely, it defines how an enterprise App shared by multiple people authenticates, including the authentication endpoint, the authentication method, and the authorization scope.
It also solves the problem of reusing credentials safely. Under the same App, when several people need to reach the same server-side resources, for example the Yuque document library of one organization, an administrator configures the credentials once and everyone else just picks the config from a dropdown when they connect.
Which authentication methods an App supports depends mainly on what the App service provider offers:
One auth config can be shared by multiple connectors, and each connector can select only one config.
For details, see Authentication overview.
A connector is one specific connection — an instance under an App card. The console lists them in the Connected users section of the App details page.
You can create multiple connectors under the same App. For example, two file connectors that hold product documentation and internal policies respectively, or two MySQL connectors that point to a test database and a production database.
Every connector includes:
A tool is a unit of capability that a connector exposes to agents. Once a connector is created successfully, Connector generates the corresponding tools based on the App type. You cannot add or remove them manually, and you do not need to.
The Available tools section on the App details page shows the input and output parameters of each tool. For example, the file connector generates two tools, search files and get file, while the table connector generates a single tool, get table schema.
Once an agent has the tools, it decides on its own which tool to call and what parameters to pass based on the user's question.
MCP is the protocol through which Connector exposes its service. You configure a single MCP endpoint in your client to reach the tools of every connected App in the current workspace.
The endpoint is scoped to the workspace, so adding or removing a connector never requires a configuration change. The client sees the latest tool list after a refresh.
A workspace is the isolation boundary for resources. Connectors, categories, files, and API Keys all belong to a workspace and are not visible across workspaces.
The
Both let agents work with enterprise data. The differences come down to three things:
Use a knowledge base when you need an answer summarized from many documents. Use Connector when you need to query a record, write a document, or send a message in a business system. You can use both together.
How it fits together
Data flows like this:
App
An App is a type of system you can connect to — each card on the Apps page of the console. It represents a class of external system, such as DingTalk Docs, Yuque, or MySQL, rather than one specific connection.
Apps fall into two categories depending on whether an auth config is required before you connect, and that determines the steps you take:
| Type | Apps included | What to do before connecting |
|---|---|---|
| Requires an auth config | Salesforce, MaxCompute, Yuque | Create an auth config first, then select it when you connect |
| Connects directly | File connector, table connector, OSS, MySQL, PostgreSQL, PolarDB-X 2.0 | Fill in everything at once in the connection dialog |
Auth config
An auth config is a definition of an authentication method together with its credentials. More precisely, it defines how an enterprise App shared by multiple people authenticates, including the authentication endpoint, the authentication method, and the authorization scope.
It also solves the problem of reusing credentials safely. Under the same App, when several people need to reach the same server-side resources, for example the Yuque document library of one organization, an administrator configures the credentials once and everyone else just picks the config from a dropdown when they connect.
Which authentication methods an App supports depends mainly on what the App service provider offers:
| Method | Console description |
|---|---|
| OAuth 2.0 | Secure, user-friendly sign-in through the OAuth 2.0 authorization flow |
| API Key | Authentication is completed with an API Key |
Connector
A connector is one specific connection — an instance under an App card. The console lists them in the Connected users section of the App details page.
You can create multiple connectors under the same App. For example, two file connectors that hold product documentation and internal policies respectively, or two MySQL connectors that point to a test database and a production database.
Every connector includes:
| Property | Description |
|---|---|
| Name | Identifies a connection among others of the same kind, up to 64 characters, editable after creation |
| Description | Explains the data content and its purpose. Agents rely on the description to decide whether to call this connector, so be specific |
| Status | Connected or Expired. The status becomes Expired once the credentials are no longer valid, and you need to authorize again |
| Credentials or storage configuration | Determined by the App type. For an App that requires an auth config, the credentials come from that config. The connector type cannot be changed after creation |
The description directly affects how accurately an agent selects a tool. Spelling out the data content and applicable scenarios is far more effective than a single noun.
Tool
A tool is a unit of capability that a connector exposes to agents. Once a connector is created successfully, Connector generates the corresponding tools based on the App type. You cannot add or remove them manually, and you do not need to.
The Available tools section on the App details page shows the input and output parameters of each tool. For example, the file connector generates two tools, search files and get file, while the table connector generates a single tool, get table schema.
Once an agent has the tools, it decides on its own which tool to call and what parameters to pass based on the user's question.
MCP
MCP is the protocol through which Connector exposes its service. You configure a single MCP endpoint in your client to reach the tools of every connected App in the current workspace.
Workspace
A workspace is the isolation boundary for resources. Connectors, categories, files, and API Keys all belong to a workspace and are not visible across workspaces.
The {workspaceId} in the MCP endpoint determines which workspace's data the client can access. If your team organizes workspaces by project, each project uses its own endpoint and API Key.
How this differs from a knowledge base
Both let agents work with enterprise data. The differences come down to three things:
| Connector | Knowledge base | |
|---|---|---|
| Pulls data in and indexes it | No pulling, chunking, or indexing. It reaches the source system directly at call time | Pulls data onto the platform, chunks it, and builds a vector index |
| Data sources covered | All kinds of enterprise systems, not limited to files and databases, including office SaaS such as Salesforce | Mainly the documents you import |
| What it provides | No retrieval. Instead it reaches into each App and supports the operations available inside it | Semantic retrieval that recalls relevant content from a large body of documents |